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Foreword 


Purpose 


Electronic  data  interchange  (EDI)  is  the  computer-to-computer  exchange  of 
routine  business  information  in  a  standard  format.  The  Department  of 
Defense  (DoD)  has  recently  launched  a  major  initiative  to  implement  EDI  in  all 
business  areas.  As  part  of  that  initiative,  this  EDI  Planning  and  Imple¬ 
mentation  Guide  is  designed  to  both  assist  DoD  activities  in  the  preparation  of 
EDI  business  plans  and  to  educate  DoD  personnel  on  EDI  matters. 


Strategic  Importance  of  EDI 


In  recent  years,  many  private-sector  companies  have  reaped  substantial 
benefits  from  automating  their  internal  operations,  such  as  accounting,  order 
entry,  purchasing,  scheduling,  and  material  processing.  Those  same 
companies  are  now  focusing  on  automating  their  external  operations  using 
EDI  and,  in  doing  so,  are  reporting  significant  economic  rewards  -  between 
$2  and  $10  or  more  in  direct  cost  savings  for  every  document  that  they 
transmit  electronically  to  their  trading  partners. 

in  spite  of  the  magnitude  of  direct  cost  savings  achieved  through  EDI,  many 
proponents  note  that  the  real  benefits  of  EDI  come  from  using  it  as  a  tool  to 
simplify  and  improve  business  procedures.  As  a  consequence,  they  are 
reporting  $3  to  $5  in  indirect  cost  savings  for  every  $1  in  direct  cost  savings 
from  various  business  improvements  made  possible  by  EDI,  such  as  reduced 
inventories,  improved  competitive  pricing  strategies,  enhanced  auditing 
procedures,  and  streamlined  operations. 

The  DoD  has  long  recognized  the  economic  and  strategic  advantages  of  EDI. 
Those  advantages  are  becoming  even  more  important  as  Defense  spending 
levels  off  or  declines.  Defense  Management  Report  Decision  941,  Imple¬ 
mentation  of  Electronic  Data  Interchange  in  DoD,  states  that  DoD  could 
achieve  direct  cost  savings  of  $548  million  through  FY99  for  an  investment  of 
$85  million  by  converting  16  of  2,100  forms  and  documents  from  paper  to  the 
electronic  medium.  It  also  prescribes  that  92  percent  of  all  DoD  business  trans¬ 
actions  be  transmitted  using  EDI  by  the  fourth  quarter  of  FY96. 


Structure  of  the  Guide 


The  figure  below  shows  how  each  chapter  and  appendix  in  the  Guide  relate  to 
each  other  and  their  roles  in  the  development  of  business  plans  and  the 
education  of  DoD  personnel.  Chapters  1,  5,  and  the  appendices  contain 
primarily  educational  material,  while  Chapters  2,  3,  and  4  provide  detailed 
guidance  on  preparing  EDI  business  plans. 
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STRUCTURE  OF  THE  GUIDE 


Chapter  1  describes  the  role  of  DoD's  Executive  Agent  for  EDI  and  Data 
Protection,  DoD's  Electronic  Commerce  Program,  the  importance  of  EDI  to 
that  program,  and  the  components  of  EDI  business  plans. 

Chapters  2,  3,  and  4  provide  detailed  assistance  in  preparing  EDI  business 
plans.  Chapter  2  presents  a  methodology  for  determining  an  activity's  most 
promising  EDI  opportunities.  Chapter  3  offers  guidance  on  putting  together 
an  economic  analysis  in  support  of  the  better  opportunities,  and  Chapter  4 
lays  out  an  approach  for  developing  EDI  implementation  plans. 

Chapters  introduces  a  number  of  legal,  security,  and  audit  issues  that  DoD 
activities  may  face  as  they  move  forward  with  EDI  applications.  Finally,  a 
series  of  appendices  provide  information  on  such  EDI  topics  as  the  history  and 
utility  of  EDI  message  standards,  transaction  sets  that  are  relevant  to  DoD, 
submission  of  proposed  EDI  projects  to  the  Executive  Agent  for  approval  and 
possible  funding  support,  frequently  used  DoD  documents,  and  a 
bibliography. 
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Chapter  1 


Introduction 


Purpose 


This  chapter  presents  background  information  on  the  Department  of 
Defense's  (DoD's)  Executive  Agent  for  Electronic  Data  Interchange  (EDI)  and 
Data  Protection;  DoD's  Electronic  Commerce  Program  and  the  role  of  EDI  in 
that  program;  and  the  need  for  each  DoD  activity  to  prepare  an  EDI  business 
plan  to  focus  and  guide  implementation  efforts. 


Role  of  the  Executive  Agent 


Although  not  new  to  DoD,  \ne  use  of  EDI  received  a  major  boost  in  May  1988 
when  then  Deputy  Secretary  of  Defense  Taft  directed  DoD  Components  to 
make  . .  maximum  use  of  electronic  data  interchange  for  the  paperless 
processing  of  all  business-related  transactions...."  He  also  charged  the 
Assistant  Secretary  of  Defense  (Production  and  Logistics),  ASD(P&L),  with 
responsibility  for  establishing  guidelines  for  "...acceptance  of  EDI  as  the 
normal  way  of  doing  business  with  DoD  by  the  early  1990's." 

In  response  to  that  charge,  the  ASD(P8»L)  designated  the  Defense  Logistics 
Agency  as  DoD's  Executive  Agent  for  EDI  and  Data  Protection  and  directed 
that  the  Executive  Agent  provide  the  leadership  required  to  implement  EDI 
throughout  DoD.  The  Executive  Agent  responded  by  formulating  a 
comprehensive  program  to  fundamentally  change  DoD's  business  practices, 
from  paper-based  document  processing  to  a  totally  electronic  environment. 
The  name  for  such  an  undertaking  is  "Electronic  Commerce  through  EDI." 

One  of  the  Executive  Agent's  first  initiatives  under  that  program  was  to 
prepare  a  DoD-wide  business  case  for  Electronic  Commerce.  (See  Hardcastle 
and  Heard,  September  1990,  in  the  Bibliography.)  The  business  case  showed 
that  over  a  10-year  period,  DoD  could  achieve  almost  $1.2  billion  in  direct  and 
indirect  cost  savings  by  electronically  processing  just  16  documents.  Those 
documents  include  several  that  are  traditionally  targeted  for  EDI  in  the 
private  sector,  such  as  purchase  orders,  invoices,  bills  of  lading,  and  requests 
for  quotations. 

The  Executive  Agent  followed  the  business  case  with  a  strategic  plan  (see 
Defense  Logistics  Agency,  November  1990,  in  the  Bibliography)  to  serve  as  a 
blueprint  for  setting  priorities  for  DoD  investments  in  Electronic  Commerce. 
Shortly  thereafter,  DoD  issued  Defense  Management  Report  Decision 
(DMRD)941,  which  established  a  goal  that  92  percent  of  DoD  business  trans¬ 
actions  be  transmitted  using  EDI  by  the  fourth  quarter  of  FY96. 

To  meet  the  DMRD  goal,  the  Office  of  Defense  Information,  Executive  Agent, 
and  Military  Services  have  been  given  resources  to  fund  various  EDI  projects. 
Those  resources  are  available  to  DoD  activities  that  propose  promising  EDI 
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projects  backed  by  solid  business  plans  explaining  associated  costs  and 
benefits.  Appendix  C  explains  the  procedures  for  DoD  activities  to  f.iiow  in 
submitting  proposed  EDI  projects  to  the  Executive  Agent. 


Electronic  Commerce 


Electronic  Commerce  is  the  integration  of  electronic  mail,  electronic  funds 
transfer  EDI,  and  similar  techniques  into  a  comprehensive,  electronic-based 
system  encompassing  all  DoD  business  functions,  including  procurement, 
payment,  supply  management,  transportation,  and  base  operations.  The 
thrust  of  DoD's  Electronic  Commerce  Program  is  not  just  to  automate  manual 
processes,  but  to  put  in  place  the  necessary  systems,  capabilities,  and 
procedures  that  will  enable  DoD  activities  to  fundamentally  alter  and  improve 
the  way  they  carry  out  their  day-to-day  business  operations.  Given  its  exten¬ 
sive  accomplishments  in  the  private  sector,  EDI  is  clearly  the  key  to  meeting 
that  objective. 


Electronic  Data  interchenge 


Electronic  data  interchange  is  the  computer-to-computer  exchange  of  routine 
business  information  in  a  standard  format.  Private-sector  firms  are  using  EDI 
to  process  purchase  orders,  shipping  notices,  receipts,  invoices,  payments,  and 
a  variety  of  other  business  documents.  In  doing  so,  they  are  reaping  a  number 
of  benefits,  including  reduced  errors  in  data  entry,  decreased  paper  handling, 
reduced  inventories,  improved  cash  management,  and  shortened  order  times. 

Several  data  exchange  techniques  are  frequently  mislabeled  as  EDI.  Some  of 
those  techniques  are  described  below,  along  with  ?hort  explanations  of  how 
they  differ  from  EDI. 

Cicsimile  (FAX)  transmission  of  a  paper  document  from  one  FAX  machine  to 
anotl.  r  (see  Figure  1-1)  is  not  EDI.  It  requires  someone  to  interpret  the 
written  data  and  rekey  it  into  an  applications  system.  Both  of  these  functions, 
in  addition  to  taking  time,  introduce  errors  into  the  processing  of  the  data. 


FIG.  1-1.  FAX 
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Electronic  mail  (E-mail)  eliminates  the  paper  associated  with  FAX,  but  it  still  is 
not  EDI.  E-mail  moves  information  directly  from  one  computer  to  another,  as 
shown  in  Figure  1-2.  Nevertheless,  the  information  moved  by  E-mail  is 
unstructured  and  requires  someone  to  interpret  the  information  and  then 
rekey  specific  data  elements  into  an  applications  system  for  additional 
processing. 


FIG.  1-2.  E-MAIL 


The  use  of  dedicated  computer  terminals  to  link  two  or  more  activities  also  is 
not  EDI  because  data  is  not  being  transmitted  in  a  standard  format  (see 
Figure  1-3).  Someone  is  still  required  to  manually  key  data  for  transmission, 
subject  to  associated  errors  and  time  delays.  Also,  in  many  cases,  someone  at 
the  receiving  activity  must  rekey  that  same  data  into  a  format  accepted  by 
internal  systems  (again  subject  to  errors  and  time  delays). 


FIG.  1-3.  DEDICATED  COMPUTER  TERMINALS 


Exchanging  data  electronically  with  a  single  trading  partner  using  non¬ 
standard  data  formats  is  a  proprietary  form  of  EDI  (see  Figure  1-4). 
Proprietary  EDI  yields  some  of  the  benefits  of  EDI  and  may  satisfy  a  single 
trading  partner  relationship,  but  it  cannot  be  readily  extended  to  additional 
trading  partners.  As  a  result,  proprietary  EDI  has  limited  application. 
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Telephone 

network 


FIG.  1-4.  PROPRIETARY  EDI 


In  contrast  to  the  above  techniques,  Figure  1-5  illustrates  a  typical  EDI 
application  between  a  DoD  buying  activity  and  its  trading  partners  (in  this 
case,  £.  vendor,  a  receiving  activity,  and  a  bank).  We  highlight  some  of  the 
features  of  this  application  below: 

•  The  DoD  buying  activity  generates  an  electronic  purchase  order  and 
sends  it  (via  a  value-added  network  or  VAN)  to  a  vendor  (1). 

•  The  vendor  ships  the  material  to  a  receiving  activity  (depot,  base, 
etc.)  (2). 

•  The  vendor  generates  an  electronic  invoice  and  sends  it  to  the  DoD 
buying  activity  (3). 

•  After  receiving  the  material  and  inspecting  it,  the  receiver  sends  an 
acceptance  report  to  the  DoD  buying  activity  (4). 

•  After  receiving  the  acceptance  report,  the  buying  activity  (or,  in 
some  cases,  a  DoD  Finance  Center)  sends  the  payment  and  a  remit¬ 
tance  advice  (using  electronic  funds  transfer)  to  its  own  bank  (5). 

•  The  buyer's  bank  electronically  sends  the  payment  and  remittance 
advice  through  the  Automated  Clearinghouse  (ACH)  network  (6)  to 
the  vendor's  bank. 

•  The  vendor's  bank  sends  a  paper  copy  of  the  remittance  advice 
(describing  the  amount  and  purpose  of  the  payment)  to  the  vendor 
(7). 


If  the  transactions  in  this  EDI  example  are  routine,  they  are  processed  entirely 
without  human  intervention  or  managerial  approval  (with  the  exception  of 
the  mailed  remittance  advice). 
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FIG.  1-5.  TYPICAL  EDI  APPLICATION 


The  keys  to  this  EDI  application  include: 

•  The  availability  of  universally  accepted  data  formats,  frequently 
referred  to  as  EDI  standards  or  transaction  sets,  to  exchange  business 
information  [American  National  Standards  Institute  (ANSI)  standards 
are  listed  in  parentheses  in  Figure  1-5] 

•  The  accessibility  of  trading  partners  (i.e.,  vendors,  carriers,  banks, 
and  DoD  activities)  to  commercial  VANs  that  receive,  store,  and 
transmit  EDI  transmissions 

•  The  capability  of  all  trading  partners  to  automatically  send,  receive, 
and  process  purchase-order,  shipment,  and  payment  information. 

The  wide  availability  of  EDI  transaction  sets  stems  primarily  from  the  efforts  of 
two  standards  groups:  the  Transportation  Data  Coordinating  Council  (TDCC) 
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and  ANSI.  Formed  in  the  1960s,  the  TDCC  (now  known  as  the  Electronic  Data 
Interchange  Association)  initially  concentrated  on  developing  standards  for 
the  transportation  industry,  but  eventually  branched  out  to  develop 
standards  for  other  industries  as  well.  As  a  result  of  TDCC's  successes, 
however,  various  companies  and  individuals  recognized  the  need  for  generic 
standards  that  cut  across  industry  lines.  In  1979,  ANSI  formed  the  Accredited 
Standards  Committee  (ASC  X12)  to  do  just  that  -  develop  uniform  standards 
for  electronically  exchanging  business  transactions  with  industries.  Those 
standards  are  now  widely  used  by  U.S.  industries.  (E DIFACT,  or  EDI  for 
Administration,  Commerce,  and  Transport,  is  the  international  EDI  message 
standard  that  is  based  largely  on  ASC  XI 2  transaction  sets.)  Appendix  B 
describes  available  EDI  transaction  sets  that  may  be  of  value  to  DoD  activities. 


EDI  Business  Plans 


In  describing  the  role  of  DoD's  Executive  Agent  for  EDI,  we  noted  that  every 
prospective  EDI  project  submitted  for  approval  and  funding  needs  to  be 
supported  by  a  business  plan.  Such  a  plan  consists  of  the  following  three 
components: 

•  An  Opportunity  Assessment  that  identifies  the  paper  documents 
that  dominate  an  activity's  workload;  evaluates  the  capability  of 
computer  systems,  both  the  activity's  and  all  trading  partners',  to 
send,  receive,  and  process  EDI  transactions;  presents  an  under¬ 
standing  of  the  business  effects  of  replacing  specific  paper  docu¬ 
ments  with  electronic  transmissions;  and,  based  on  these  results, 
formulates  a  list  of  promising  EDI  applications. 

•  An  Economic  Analysis,  building  upon  an  operating  concept  for  each 
EDI  application,  that  includes  the  calculation  of  direct  and  indirect 
cost  savings,  investment  costs,  and  rates  of  return  for  each  EDI 
application.  The  results  of  these  calculations  yield  a  list  of  potential 
EDI  applications  in  order  of  priority. 

•  An  Implementation  Plan  that  identifies,  sequences,  and  schedules  all 
the  events  necessary  to  implement  the  activity's  most  promising  EDI 
application. 

In  Chapters  2,  3,  and  4  of  this  Guide,  we  provide  a  detailed,  step-by-step 
approach,  complete  with  worksheets,  to  performing  an  EDI  opportunity 
assessment,  conducting  an  economic  analysis  of  the  most  promising  oppor¬ 
tunities,  and  preparing  an  implementation  plan  for  those  opportunities  that 
offer  substantial  economic  advantage. 


I 


Chapter  2  Identifying  EDI  Opportunities 


Purpose 


This  chapter  presents  a  methodology  for  identifying  an  activity's  most 
promising  EDI  opportunities.  Making  extensive  use  of  worksheets,  the 
methodology  consists  of  five  steps: 

•  Selecting  key  documents 

•  Assessing  an  activity's  capability  to  support  EDI  applications 

•  Analyzing  trading  partner  capabilities 

•  Determining  effect  of  EDI  on  business  practices 

•  Identifying  best  EDI  opportunities. 

At  the  conclusion  of  these  five  steps,  an  activity  will  have  identified  all 
documents  that  are  promising  candidates  for  replacement  by  EDI.  Those 
documents  then  need  to  be  subjected  to  a  detailed  economic  analysis, 
following  the  methodology  presented  in  Chapter  3,  to  ensure  that  the  activity 
would  actually  benefit  from  such  replacements. 


Selection  of  Key  Documents 


Much  of  the  savings  from  EDI  occur  because  electronic  processing  of  docu¬ 
ments  is  less  costly  than  manual  processing.  As  a  consequence,  the  number  of 
times  that  an  activity  sends  or  receives  a  particular  document  (i.e.,  its  volume) 
is  the  primary  criterion  in  selecting  documents  for  potential  transmission  by 
EDI.  But  volume  is  not  the  only  consideration.  The  document  also  should  be 

•  Used  extensively  throughout  DoD 

•  Processed  manually 

•  Handled  by  several  departments  within  the  activity 

•  Supported  by  an  existing  EDI  transaction  set. 

Note:  Although  time-consuming,  an  activity  may  find  it  advantageous  to 
create  a  new  transaction  set  for  selected  high-volume  documents  that  lack  an 
EDI  transaction  set  (see  Chapter  4). 

To  aid  in  identifying  the  most  promising  EDI  applications,  activities  should  fill 
out  Worksheet  2-1  for  all  paper  documents  or  transactions  under  consider¬ 
ation.  The  first  step  in  using  that  worksheet  is  to  match  each  document  or 
transaction  with  its  EDI  transaction  set.  You  may  wish  to  consult  Appendices  B 
and  D  when  completing  this  worksheet.  Appendix  B  contains  a  listing  of  all 
approved  ASC  XI 2  transaction  sets  as  well  as  those  under  development.  It 
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Atofe  E= Excellent  (vol.  >  100,000);  S= Satisfactory  (wol.  >10,000  but  <  100,000);  M= Marginal  (vol.  <  10,000). 
*  More  then  one  transaction  set  may  be  listed  for  some  documents. 
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also  attempts  to  match  key  DoD  documents  and  reports  with  the  appropriate 
transaction  set.  Appendix  D  describes  the  16  key  documents  that  were 
included  in  DMRD  941 . 

Next,  the  activity  enters  the  estimated  number  of  documents  sent  and 
received  each  year  on  the  worksheet.  If  the  total  number  of  documents  sent 
and  received  exceeds  100,000,  place  an  “E“  for  Excellent  in  the  volume  rating 
column.  If  the  total  is  between  10,000  and  100,000,  assign  a  rating  of  '5'  for 
Satisfactory.  If  the  total  is  under  10,000,  give  it  a  rating  of  * M"  for  Marginal. 

Note:  Under  some  circumstances,  however,  documents  assigned  a 

M-rating  may  still  warrant  replacement  by  EDI  because  either  they  contain  a 
large  number  of  line  items,  or  they  are  key  to  transmitting  other,  high-volume 
documents  by  EDI. 


Capability  of  Internal  Systems 


Following  identification  of  the  best  candidates  for  EDI,  the  activity  should 
then  assess  its  capability  to  send,  receive,  and  process  EDI  documents 
internally.  Activities  that  fail  to  achieve  expected  levels  of  EDI  savings  often 
neglect  this  important  step. 

Worksheet  2-2  is  designed  to  aid  an  activity  in  assessing  the  capabilities  of  its 
internal  systems.  The  worksheet  is  divided  into  two  parts.  The  first  part  helps 
the  activity  construct  an  inventory  of  the  internal  systems  used  to  process  a 
document  or  category  of  documents  such  as  the  hardware  platform,  systems 
software,  and  applications  programs.  The  second  part  focuses  on  any 
modifications  required  to  those  internal  systems  to  accommodate  EDI. 

In  completing  Part  II  of  this  worksheet,  activities  are  advised  to  refer  to  the 
document  volumes  presented  in  Worksheet  2-1,  since  volume  may  have  a 
significant  impact  on  hardware  and  system  software  requirements.  The 
activity  should  also  ask  itself  whether  the  proposed  EDI  application  will  have 
an  impact  on  any  other  applications  programs  or  software  systems  that  may 
run  on  the  same  hardware  platform  as  the  proposed  EDI  system. 

The  objective  of  this  analysis  is  to  help  an  activity  to  quickly  identify  any  major 
impediments  to  implementing  EDI  for  the  documents  or  categories  of 
documents  listed  in  Worksheet  2-1.  A  detailed  analysis  of  EDI  data  require¬ 
ments,  although  helpful,  is  not  required  at  this  stage. 

At  the  bottom  of  the  worksheet,  the  activity  rates  the  EDI  capability  of  its 
applications  systems,  using  the  following  criteria: 

•  Excellent  EDI  capability.  Internal  systems  usually  merit  such  a  rating 
if  they  require  little  or  no  modifications  to  enable  them  to  send, 
receive,  and  process  EDI  transactions. 

•  Satisfactory  EDI  capability.  These  systems  need  substantial 
modification  before  they  can  become  EDI-capable.  Older  DoD 
internal  systems  tend  to  fall  into  this  category. 

•  Marginal  EDI  capability.  A  marginal  rating  is  merited  when  a 
particular  document  (or  category  of  documents)  is  not  supported  by 
an  applications  system,  or  if  the  existing  applications  system  cannot 
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Activity: 

I.  Internal  Systems  Inventory 

Document  (or  Document  Category):  _ 

Name  of  Applications  Programs :  _ 

Year  Developed:  _ 

Hardware:  _ 

Operating  System:  _ 

Software:  _ 

Data  Base  Management  System :  _ 

Supporting  Systems:  _ 

Planned  Enhancements:  _ _ _ 


Relevant  EDI  /Electronic  Commerce  Initiatives: 


II.  Internal  Systems  Assessment 

(Note:  Use  document  volumes  presented  in  Worksheet  2-1  to  answer  the  following 
questions) 

Modifications  Required  to  Implement  EDI? 

Yes  No  Enhancements  required  (or  comments) 

Hardware  platform  _  _  _ 


Software  systems 


Applications  programs 


EDI  Capability  Rating:  E  □  (Excellent) 

S  □  (Satisfactory) 

M  □  (Marginal) 
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receive  or  transmit  electronic  transmissions.  As  a  consequence,  the 
activity  could  not  implement  EDI  in  this  area  until  it  overcomes  these 
obstacles. 


Capability  of  Trading  Partners 


Each  activity  has  two  categories  of  trading  partners:  internal  (i.e.,  other  DoD 
activities)  and  external  (i.e.,  commercial  organizations).  This  distinction  is 
important  because  the  activity  needs  to  estimate  the  investment  required  by 
its  internal  trading  partners  to  implement  EDI  following  the  methodology 
presented  in  Chapter  3. 

Worksheet  2-3  provides  a  form  for  profiling  the  capabilities  of  the  activity's 
internal  trading  partners  for  each  document  identified  in  the  Document 
Volume  Worksheet  (2-1).  The  Internal  Trading  Partner  Profile  Worksheet  calls 
for  a  list  of  DoD  activities  with  which  the  document  is  exchanged;  the  parent 
Military  Service  or  Defense  agency  of  those  activities;  the  automated  systems 
used  by  each  activity;  the  capability  of  those  systems  to  send,  receive,  and 
process  EDI  transactions;  and  the  number  of  documents  exchanged  each  year 
with  that  activity. 

At  the  bottom  of  the  Internal  Trading  Partner  Profile  Worksheet,  the  activity 
shows  the  number  of  trading  partners  required  to  reach  a  70  to  80  percent 
implementation  level  (in  terms  of  number  of  transactions)  for  that  document. 
(Many  private-sector  firms  use  this  range  as  the  "critical  mass"  level  for 
achieving  the  economies  of  scale  associated  with  EDI.)  Then,  the  activity 
applies  the  following  criteria  to  assess  the  capability  of  its  internal  trading 
partners  to  exchange  documents  electronically: 

•  Excellent,  if  a  small  number  of  trading  partners  are  required  to  reach 
a  70  to  80  percent  implementation  level  and  most  of  them  are  EDI- 
capable 

•  Satisfactory,  if  a  moderate  number  of  trading  partners  are  required 
to  reach  that  same  threshold  and  most  are  EDI-capable 

•  Marginal,  if  either  the  number  of  required  trading  partners  are 
numerous  or  most  of  the  activity's  trading  partners  are  not  EDI- 
capable. 

Note:  Depending  on  individual  circumstances,  DoD  activities  may  differ  in 

the  way  they  define  the  terms  small,  moderate,  and  numerous  with  respect  to 
trading  partners.  For  example,  high-volume  activities  with  EDI-capable 
trading  partners  can  usually  accommodate  a  larger  number  of  trading 
partners  than  small-volume  activities  without  EDI-capable  trading  partners. 
As  a  general  rule,  however,  the  smaller  the  number  of  trading  partners 
involved,  the  faster  critical  mass  will  be  achieved.  (See  Chapters  4  and  5  for 
more  information  on  soliciting  trading  partners). 

The  External  Trading  Partner  P/ofile  Worksheet  (see  Worksheet  2-4)  is  similar 
to  that  used  for  internal  trading  partners.  However,  instead  of  identifying  the 
applications  systems  used  by  the  activity's  external  trading  partners,  the 
worksheet  provides  a  column  to  indicate  if  the  organization  is  EDI-capable. 
The  activity  can  obtain  this  information  either  directly  from  the  trading 
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WORKSHEET  »-8  -  INTERNAL  TRADING  PARTNER  PROFILE 


Document: 


Activity: 


DoD  trading  Military  Service/  Automated 

partner  Defense  agency  system 


EDI  capability  I  Number  per  year 


Yes 

No 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

H 

□ 

□ 

□ 

□ 

□ 

□ 

G 

□ 

□ 

□ 

□ 

□ 

Number  of  trading  partners  required  to  achieve  a  70  -80  percent  implementation  rate  (critical  mass):  _ 

Trading  partner  rating:  E  □  S  □  Mo  (E  =  Excellent;  S= Satisfactory;  M  =  Marginal) 
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partner  or  from  other  sources  such  as  the  EDI  Yellow  Pages:  Business  Partner 
Directory,  September  1991  -  August  1992  (see  Appendix  E,  Bibliography). 


Review  of  Business  Practices 


In  determining  whether  or  not  a  document  is  a  good  EDI  opportunity,  each 
activity  needs  to  consider  its  specific  business  practices.  For  example,  before 
making  payment  on  an  invoice,  many  activities  require  a  record  of  acceptance 
showing  that  delivery  has  occurred  and  that  the  material  received  is  not 
defective.  If  invoices  are  received  electronically  and  acceptance  notices  are 
received  manually,  the  number  of  late  payments  could  actually  increase 
rather  than  decrease  with  EDI.  Although  legal  and  security  requirements  also 
can  impede  implementation  of  EDI  at  some  activities,  they  are  addressed 
separately  in  Chapter  5  of  this  Guide.  (Drake  et  al.,  April  1990  and  June  1991 
in  the  Bibliography,  provide  an  extensive  discussion  of  EDI  legal  and 
regulatory  issues.)  In  fact,  many  private-sector  companies  have  found  that 
they  cannot  make  effective  use  of  EDI  without  changing  their  internal 
business  practices. 

To  aid  in  identifying  business  practices  that  may  affect  replacement  of  a 
particular  paper  document  with  EDI,  Worksheet  2-5  provides  a  checklist  of 
questions.  Those  questions  are  designed  to  surface  any  unique  business 
practices  of  the  activity  that  must  either  be  accommodated  by  the  EDI 
application  or  modified  before  implementation  begins. 

After  answering  the  questions  on  the  Business  Practices  Worksheet,  the 
activity  assigns  a  rating  to  each  document  based  upon  the  effects  of  its 
business  practices  on  replacing  that  document  with  electronic  transmissions. 
The  following  criteria  are  suggested:  Excellent  -  no  significant  business 
issues  exist;  Satisfactory  -  some  business  issues  exist,  but  they  should  not 
seriously  impede  implementation;  Marginal  -  one  or  more  major  business 
issues  need  to  be  resolved  before  the  activity  can  begin  implementation. 


Summary  of  EDI  Opportunities 


Upon  completion  of  the  Business  Practices  Worksheet,  the  activity  is  now 
prepared  to  summarize  its  findings  on  EDI  opportunities,  using  Work¬ 
sheet  2-6. 

For  each  document,  the  activity  lists  the  corresponding  EDI  transaction  set; 
the  volume  rating  from  the  Document  Volume  Worksheet  (2-1);  the  EDI 
capability  rating  of  the  internal  systems  from  the  Internal  System  Profile 
Worksheet  (2-2);  the  ratings  for  both  the  internal  and  external  trading 
partners  (Worksheets  2-3  and  2-4);  and  the  business  practices  rating  from  the 
Business  Practices  Worksheet. 

Using  this  information,  the  activity  then  assigns  an  overall  opportunity  rating 
to  each  document.  Although  highly  subjective,  the  following  approach  is  one 
way  to  construct  a  composite  rating:  Assign  an  overall  rating  of  E  (Excellent) 
if  an  EDI  transaction  set  exists  and  the  document  receives  three  or  more 
individual  excellent  ratings;  a  rating  of  5  (Satisfactory)  if  an  EDI  transaction  set 
exists  and  the  document  receives  one  or  two  individual  excellent  ratings;  a 
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Document: 


Practices 


Activity:  _ 


CHECKLIST 


Yes  □ 

No 

□ 

Yes  □ 

No 

□ 

Yes  □ 

No 

□ 

Yes  □ 

No 

□ 

TRANSACTION  SETS 

Docs  an  EDI  transaction  set  (see  Appendix  B  of  the  Guide)  exist  for  this  document? 

If  yes,  does  the  transaction  set  accommodate  all  the  information  that 
the  activity  traditionally  sends? 

If  no,  is  the  extra  information  necessary? 

Is  it  available  from  other  documents? 

NOTE :  If  a  transaction  set  needs  to  be  modified,  the  activity  should  contact  the  Executive  Agent,  who 
would  then  initiate  the  process  for  requesting  a  change. 


INFORMATION  FLOWS 

Does  the  processing  of  this  document  (i.e.,  the  flow  of  paper)  within  the  activity  need  to 
be  changed  to  accommodate  an  electronic  environment? 

What  steps  in  that  processing  can  be  eliminated  or  consolidated  by  not  using  a  paper  document? 


What  steps  need  information  from  other  documents  before  they  can  be  satisfied? 


Is  that  information  vital? 

Yes  □ 

No 

□ 

Are  those  other  documents  received  or  sent  by  EDI? 

Yes  □  No  □  If  yes,  Received  □ 

Sent 

□ 

if  no,  should  they  be  received  or  sent  by  EDI? 

Received  □ 

Sent 

a 

SKOAL  REQUIREMENTS 

Does  the  document  have  any  special  processing,  handling,  legal,  or  security  requirements? 
Are  those  requirements  necessary? 

How  are  these  requirements  satisfied  in  a  paper  environment?  _ 


Yes  □  No  □ 
Yes  □  No  a 


How  could  they  be  satisfied  in  an  electronic  environment? 


Business  practices  rating:  E  □  SO  Mo  (E  =  Excellent;  S= Satisfactory;  M  =  Marginal) 
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rating  of  M  (Marginal)  if  no  EDI  transaction  set  exists  or  the  activity  has  major 
shortcomings  in  two  or  more  categories. 

After  completing  the  EDI  Opportunities  Worksheet,  the  activity  will  have  a 
good  perspective  on  those  documents  that  are  candidates  for  EDI.  We 
suggest  that  all  documents  receiving  either  an  E  or  an  S  rating  be  subjected  to 
an  economic  analysis  following  the  methodology  presented  in  Chapter  3. 


2-11 


Chapter  3 


Conducting  Economic 

Analyses 


Purpose 


This  chapter  presents  a  methodology  for  assessing  the  economic  effects  of 
replacing  the  paper  documents  identified  in  Chapter  2  with  electronic 
transmissions.  Again,  we  make  extensive  use  of  worksheets  to  guide  the 
activity  in  applying  the  methodology.  The  methodology  concludes  with  the 
preparation  of  an  EDI  priority  list,  which  forms  the  basis  for  development  of 
EDI  implementation  plans  in  Chapter  4. 

Note:  The  Office  of  Defense  Information  has  recently  developed  an 

abbreviated  Functional  Economic  Analysis  (FEA)  form  that  must  be  completed 
by  activities  requesting  funding  for  FY92  automation  projects  through  either 
the  Executive  Agent  or  the  Corporate  Information  Management  (CIM) 
program.  That  form,  along  with  supporting  documentation,  is  contained  in 
Appendix  C.  The  FEA  requires  DoD  activities  to  submit  for  each  automation 
project,  estimates  of  the  activity's  baseline  operating  costs,  along  with  the 
investment  required  and  benefits  generated  by  the  proposed  automation 
project  throughout  its  expected  life. 

The  methodology  described  in  this  chapter  will  assist  activities  in  completing 
the  Investment  and  Benefit  sections  of  the  abbreviated  FEA  form.  To  finish 
the  FEA  form,  the  activity  must  also  supply  an  estimate  of  its  baseline  operat¬ 
ing  costs  over  the  project  life  cycle.  Please  contact  the  Executive  Agent  or  the 
Office  of  Defense  Information  for  more  details  concerning  the  abbreviated 
FEA  or  any  new  FEA  formats  that  may  emerge  in  the  future. 


Estimating  Benefits 


The  benefits  that  result  from  implementing  EDI  can  be  divided  into  two 
categories:  direct  and  indirect.  We  describe  each  of  these  categories  in  more 
detail  below. 

Direct  Benefits 


Although  DoD  has  no  single  set  of  procedures  for  processing  and  distributing 
the  approximately  2,100  paper  forms  that  it  uses  to  conduct  business,  those 
forms  share  a  number  of  common  processing  operations.  These  include 
distribution  (making  copies  of  documents  and  distributing  them  among 
users);  mailing;  sorting,  reconciling  and  auditing;  data  entry,  which  occur 
several  times  if  the  same  information  is  entered  into  more  than  one  computer 
system;  error  resolution  (checking  for  and  correcting  mistakes);  storage  and 
retrieval;  and,  for  some  documents,  placement  of  procurement  orders  by 
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telephone.  Since  EDI  eliminates  most  of  these  operations,  we  consider  the 
associated  savings  to  be  direct  benefits. 

Table  3-1  lists  these  processing  operations  along  with  three  estimates  of 
projected  savings  (on  a  per-document  basis)  that  could  result  if  DoD  replaced 
the  manual  processing  with  EDI.  (The  savings  figures  are  based  upon 
engineered  work  standards  developed  by  the  Defense  Finance  and 
Accounting  Service  -  Indianapolis  Center;  see  A  Business  Case  for  Electronic 
Commerce,  Hardcastle  and  Heard,  September  1990,  in  the  Bibliography.)  The 
estimates  are  based  upon  the  complexity  of  the  operations  being  eliminated. 
For  example,  a  highly  complex  document  will  be  more  expensive  to  process 
than  a  medium-  or  low-complex  document. 

Using  the  savings  estimates  in  Table  3-1,  we  computed  the  direct  savings  of 
replacing  16  frequently  used  DoD  documents  with  EDI.  Table  3-2  lists  the 
16  documents,  while  Table  3-3  shows  the  savings.  (Appendix  D  provides  a 
brief  description  of  the  uses  of  those  documents.)  The  savings  range  from  a 
low  of  $0.69  for  each  Voucher  Stub  and  Check  replaced  by  EDI  to  a  high  of 
$6.07  for  every  Material  Inspection  and  Receiving  Report. 

Worksheet  3-1  is  provided  to  aid  in  determining  the  direct  benefits  or  cost 
savings  from  replacing  specific  documents  with  EDI.  For  each  document,  the 
activity  lists  the  number  processed  each  year.  If  the  document  is  included  in 
Table  3-3,  the  activity  may  use  the  total  direct  cost  savings  shown  in  that  table 
as  the  worksheet  entry  in  the  “Cost  savings/document”  column.  The  “Total 
savings  per  year”  is  then  obtained  by  multiplying  the  annual  volume  by  the 
savings  per  document.  If  the  document  is  not  listed  in  Table  3-3  or  if  it  is 
processed  in  a  unique  manner,  the  activity  may  need  to  develop  its  own 
estimate  of  direct  cost  savings  per  document  using  variations  of  the  data 
presented  in  Table  3-1 . 

Indirect  Benefits 


Many  private-sector  companies  have  found  that  EDI  can  result  in  significant 
savings  in  addition  to  those  resulting  from  replacing  manual  processes  with 
electronic  transmissions.  They  cite  reductions  in  inventories,  improvements  in 
customer  service,  and  streamlined  operations  as  additional,  yet  indirect, 
benefits  of  EDI.  The  DoD  is  likely  to  experience  many  of  those  same  benefits, 
as  well  as  others,  such  as  improved  quality  control,  enhanced  contract 
management  and  auditing,  increased  price  discounts,  and  reduced  interest 
payments.  These  indirect  benefits  typically  result  from  changes  in  business 
practices  made  possible  by  EDI. 

Although  the  indirect  benefits  from  EDI  have  the  potential  to  be  substantially 
larger  than  the  direct  benefits,  they  are  more  difficult  to  estimate.  Some 
studies  indicate  that  the  indirect  savings  may  exceed  direct  savings  by  a  factor 
of  three  (see  Arthur  D.  Little,  April  1980,  in  the  Bibliography).  In  others,  such 
as  DoD's  EDI  program  for  transportation,  the  indirect-to-direct  benefits  ratio 
is  estimated  to  be  a  more  modest  1 .8  to  1 . 

The  Indirect  Cost  Savings  Worksheet  (Worksheet  3-2)  allows  an  activity  to 
summarize  the  indirect  benefits  that  may  result  from  electronically  trans¬ 
mitting  specific  documents.  In  addition  to  listing  the  cost  savings,  the  activity 
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TABLE  3-1 

DIRECT  COST  SAVINGS  THROUGH  EDI 


Operation 

Activity 

Comment 

Savings  per  document 

Low 

complexity 

($) 

Medium 

complexity 

(S) 

High 

complexity 

($) 

Document 

distribution 

Separate  documents, 
make  copies,  route 
to  mail  room, 
prepare  address 
labels,  and  stuff 
envelopes 

Costs  increase  with 
complexity  of 
operation 

0.02 

0.04 

0.06 

Mailing 

Place  material  in 
envelopes  and  apply 
stamps 

Costs  increase  with 
number  of 
documents  requiring 
single  envelopes 

0.11 

0.16 

0.26 

Document 

receipt 

Receive,  open,  sort, 
date,  stamp,  and 
route 

Costs  increase  with 
complexity  of  sorting 

0.01 

0.02 

0.03 

Document 

processing 

Match,  reconcile, 
audit,  and  general 
document  processing 

Costs  increase  with 
complexity  of 
document  and 
volume  of  data 

0.15 

0.26 

0.41 

Document 
preparation 
and  control 

Examine  and  prepare 
document  for  data 
entry 

Costs  increase  with 
complexity  of 
document 

0.13 

0.21 

0.47 

Data  entry 

Enter  data  in  system 

Costs  increase  with 
volume  of  data 

0.06 

0.17 

0.68 

Error  resolution 

Research  and  correct 
errors,  and  prepare 
correspondence 

Costs  increase  with 
volume  of  data 

0.05 

0.07 

0.09 

Document 
storage  and 
retrieval 

Log,  separate,  sort, 
microfilm,  box,  file, 
and  retrieve 
documents 

Costs  increase  with 
filing  and 
microfilming 
requirements 

0.10 

0.16 

0.28 

Telephone 

procurement 

Purchase  materials  or 
services 

Costs  increase  with 
percent  of  telephone 
solicitations 

1.78 

3.50 

5.33 
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TABLE  3-2 

FREQUENTLY  USED  DoD  DOCUMENTS 


Application  area/document 

Title 

Procurement/Contract  Administration 

DD  Form  2S0 

Material  Inspection  and  Receiving  Report 

DD  Form  1155 

Order  for  Supplies  and  Services 

SF  18 

Request  for  Quotations  (Written) 

SF  18 

Request  for  Quotations  (Telephone) 

SF  30 

Amendment  of  Solicitation/Contract  Modification 
(Local) 

SF  30 

Amendment  of  Solicitation/Contract  Modification 
(Non-Local) 

SF  129 

Solicitation  Mailing  List  Application 

SF  1443 

Contractor's  Request  for  Progress  Payments 

Transportation 

SF  1103,  SF  1113 

Freight  GBL,  CBL,  and  Public  Voucher 

SF  1 169,  SF  1113 

Government  Travel  Request  and  Public  Voucher 

SF  1203, 619/619-1,  SF  1113 

Personal  Property  GBL,  Statement  of  Accessorial 

Services  Performed,  and  Public  Voucher 

— 

Voucher  Stub  and  Check 

MT364R 

Standard  Tender 

Supply /Maintenance 

SAV  926 

Monthly  Report  of  Repairables 

SF  361 

Transportation  Discrepancy  Report 

SF  364 

Report  of  Discrepancy  (Supply) 

SF  368 

Product  Quality  Deficiency  Report 

Fuels 

DD  Form  1898 

Aviation  Fuels  Sales  Slip 

Not*:  DD = Department  of  Defense;  Sf=  Standard  Form;  MT= Military  Tender;  SAV=Standard  Aviation;  GBL  = 
Government  bill  of  lading;  CBL= commercial  bill  of  lading. 
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TABLE  3-3 

DIRECT  COST  SAVINGS  FOR  FREQUENTLY  USED  DoD  DOCUMENTS 

(Dollars) 


Document  distribution 
Mailing 

Document  receipt 
Document  processing 

Document  preparation 
and  control 

Data  entry 

Error  resolution 

Document  storage  and 
retrieval 

Telephone  procurement 


SF30 

(local) 

SF  30 
(non¬ 
local) 

0.04 

0.06 

0.26 

0.26 

0.07 

0.14 

0.82 

1.53 

0.76 

1.41 

0.57 

0.92 

0.32 

0.29 

0.68 

0.38 

3.52 

4.99 

SF1443 

SF1103/ 

SF1113 

0.04 

0.06 

0.11 

0.16 

0.02 

0.08 

0.41 

1.04 

0.34 

0.89 

0.17 

0.97 

0.12 

0.26 

0.16 

0.16 

1.37 

3.62 

SF 1169/  SF 1203/ 
SF1113  SF  1113 


Voucher 

Stub/ 

Chech 


Document  distribution 
Mailing 

Document  receipt 
Document  processing 

Document  preparation 
and  control 

Data  entry 

Error  resolution 

Document  storage  and 
retrieval 


Telephone  procurement 


0.06 

0.06 

0.11 

0.16 

0.03 

0.09 

0.78 

1.45 

0.52 

1.36 

0.18 

1.14 

0.15 

0.31 

0.16 

0.32 

SAV926  SF  361 


SF  364  SF  368  D0 1898 


0.04 

0.06 

0.06 

0.04 

0.16 

0.52 

0.42 

0.52 

0.01 

0.03 

0.08 

0.04 

0.26 

0.67 

0.82 

0.41 

0.60 

0.39 

0.68 

0.34 

0.68 

0.06 

0.34 

0.17 

0.09 

0.05 

0.14 

0.07 

0.16 

0.16 

0.16 

0.16 

Document 


Annual  volume 


Cost  savings/ 
document  ($) 


Total  savings 
per  year  ($) 
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should  describe  in  the  "Comments'*  column  how  it  will  achieve  those  benefits. 
Supporting  analyses  may  need  to  accompany  the  completed  worksheet. 

Life-Cycle  Cost  Savings  _ 


The  activity  is  now  ready  to  compute  an  estimated  stream  of  savings  for  each 
document  over  the  expected  life  of  the  EDI  project.  Worksheet  3-3  is  provided 
to  aid  in  estimating  that  stream  of  savings.  For  each  document,  the  activity 
lists  the  direct  and  indirect  savings  totals  from  Worksheets  3-1  and  3-2.  The 
sum  of  those  values  gives  the  annual  savings  from  EDI  if  100  percent  of  the 
documents  are  transmitted  electronically.  Of  course,  100  percent  implemen¬ 
tation  for  any  document  is  highly  unlikely  because  some  trading  partners  may 
not  send  enough  documents  to  warrant  an  investment  in  EDI.  For  those 
trading  partners,  the  activity  will  continue  to  use  paper. 

Many  organizations  find  that  80  percent  of  their  business  transactions  are 
conducted  with  20  percent  of  their  trading  partners.  Called  the  80/20  rule,  it 
focuses  an  activity's  attention  on  its  high-volume  trading  partners  because 
they  will  yield  the  greatest  return  on  investment. 

After  obtaining  its  critical  mass  level,  the  activity  determines  the  number  of 
years  it  will  take  to  reach  that  level.  An  activity  may  use  a  variety  of 
techniques  to  develop  an  estimated  rate  of  implementation  for  each 
document;  one  simple  method  is  to  query  several  activity  personnel  and  then 
average  their  rates. 

An  activity  typically  should  allow  at  least  5  to  6  years  to  achieve  its  target 
implementation  goal.  Most  private-sector  companies  plan  for  an  imple¬ 
mentation  rate  of  less  than  15  percent  during  the  first  2  years  of  an  EDI 
project,  primarily  because  of  the  time  required  to  procure  hardware  and 
software,  develop  EDI  conventions,  and  make  the  necessary  enhancements  to 
internal  applications  systems  and  operating  procedures. 

Once  the  activity  has  decided  on  a  rate  of  implementation,  it  multiplies  the 
annual  savings  by  each  year's  implementation  rate  over  the  duration  of  the 
project.  We  suggest  a  10-year  life  cycle  for  most  EDI  projects,  but  an  activity 
may  select  shorter  or  longer  life  cycles.  The  yearly  savings  are  then  added  over 
the  duration  of  the  project  to  produce  the  total  life-cycle  savings  expected  for 
that  document,  shown  as  the  total  of  the  annual  savings  in  Worksheet  3-3. 

Upon  completing  an  EDI  Life-Cycle  Savings  Worksheet  for  each  prospective 
document,  the  activity  combines  the  results  on  the  Total  Life-Cycle  Savings 
Worksheet  (Worksheet  3-4).  That  worksheet,  when  completed,  shows  the 
total  expected  savings  from  EDI  and  the  amount  that  each  document 
contributes  to  the  total  by  year. 


Developing  Operating  Concepts 


Once  the  activity  estimates  the  total  life-cycle  savings  for  each  document,  it 
then  formulates  an  operating  concept  that  outlines  how  it  will  replace  the 
flow  of  paper  with  electronically  transmitted  information.  The  operating 
concept  should  depict  the  information  flows  between  the  activity  and  its 
trading  partners,  along  with  the  technical  configuration  (hardware, 
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W08SSHBET34  -  INDIRECT  COST  SAVINGS 


Document: 


Activity: 


indirect  Benefit:  Reduced  inventory 


Cost  Savings: 


indirect  Benefit:  Streamlined  operations  Cost  Savings: 


indirect  Benefit:  Enhanced  auditing  and  Cost  Savings: 
accounting 


Indirect  Benefit:  Increased  use  of  payment  Cost  Savings: 

discounts 


Indirect  Benefit:  Reduced  interest  payments  Cost  Savings: 


Other  Indirect  Benefit: 


Other  Indirect  Benefit: 


Other  Indirect  Benefit 


Cost  Savings: 


Cost  Savings: 
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software,  and  telecommunications)  required  to  transmit  and  receive  that 
information.  The  operating  concept  serves  as  a  basis  for  estimating  the 
activity's  EDI  investment  costs. 

Figure  3*1  shows  an  example  of  information  flows  between  an  activity  and  its 
trading  partners,  and  the  EDI  transaction  sets  supporting  those  flows. 
Figure  3-2  depicts  an  EDI  technical  configuration  that  accommodates  the 
information  flows  shown  in  Figure  3-1.  Although  we  do  not  highlight  the  EDI 
translation  software,  it  resides  on  the  EDI  host,  as  does  the  software  for 
routing  transactions  to  the  appropriate  applications  systems  (if  required). 

In  these  examples,  we  separated  the  information  flows  from  the  technical 
configuration  to  clearly  depict  the  purpose  and  value  of  each  step.  The 
activity,  however,  may  elect  to  combine  the  information  flows  and  technical 
configuration  into  a  single  diagram  and  consolidate  several  documents  into  a 
single  operating  concept,  provided  those  documents  support  a  single  mission. 

Note:  The  activity  should  contact  the  Executive  Agent  to  discuss  unusual 
technical  configuration  issues. 


Estimating  Investment  Costs 


The  investment  costs  of  any  EDI  initiative  fall  into  one  of  six  categories: 

•  Hardware 

•  Software 

•  Telecommunications 

•  Systems  integration 

•  Program  management 

•  Implementation  support. 

We  discuss  each  of  these  cost  categories  below. 

Note:  The  Executive  Agent  for  EDI  is  investigating  the  development  of  a 
standard  EDI  hardware,  software,  and  telecommunications  platform.  Please 
contact  the  Executive  Agent  for  more  information  about  the  status  of  that 
platform. 

Hardware 


The  technical  configuration  portion  of  the  operating  concept  determines 
most  of  the  hardware  investment  costs.  Private-sector  companies  typically  use 
either  a  front-end  or  a  host  configuration.  In  the  front-end  configuration,  EDI 
translation  software  resides  on  either  a  minicomputer  or  microcomputer. 
That  computer  passes  EDI  files  to  and  from  the  applications  system  software, 
which  is  resident  on  a  different  computer  (usually  a  mainframe).  In  a  host 
configuration,  the  EDI  translation  software  resides  on  the  same  computer  as 
the  applications  software. 

In  a  front-end  configuration,  we  suggest  that  the  activity  budget  $5,000  for  a 
microcomputer  and  at  least  $30,000  for  a  minicomputer.  (The  cost  of  a 
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Contract  management 
activity 


Source 
Acceptance 
(direct  input) 


Contract 
Modification 
(ANSI  860) 


Contract 
(ANSI  850) 


Material  Inspection 
and  Receiving  Report 
(ANSI  856) 


Remittance  Advice 
(ANSI'820)^ 

Invoice 

Bank  y  (ANSI  810)/ 

Payment  Order/ 

Remittance  Advice 
(ANSI  820) 


Contract  Payment 
Notice 
(ANSI  820/ 
MILSCAP) 


Shipment 
Performance 
Notice 
(ANSI  860) 


Vendor 


N 


Material  Inspection 
and  Receiving  Report 
(ANSI  856) 


Finance  center 


Contract 

Modification _ I 

(ANSI  860) 

Contract  _ 

(ANSI  850) 

Buying  activity 

It:  MUSCAT  ■  MiHtRry  Stands  Contract  Administration  l>wcidum. 


Destination 
Acceptance  Alert' 
(ANSI  856/MILSCAP) 


Destination 
|_  Acceptance  Report 
(ANSI  861) 


Receiver 


FIG.  3*1.  EXAMPLE  -  EDI  INFORMATION  FLOWS 
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ft 

Network  Application  Support  9080 
Application  System  #1 


Application  System  #3 
(not  yet  implemented) 


AMDAHL  5880/5870 
Application  System  #2 


FIG.  3-2.  EXAMPLE  -  EDI  TECHNICAL  CONFIGURATION 


minicomputer  could  be  substantially  higher  depending  on  the  activity's 
specific  storage  requirements.)  Some  operating  concepts  could  even  require 
more  than  one  computer. 

The  choice  of  hardware  depends  upon  a  number  of  considerations:  volume 
(number  of  EDI  transactions  per  day);  processing  speed,  including  that  of 
translation  software;  and  storage  requirements,  such  as  archiving  a  large 
number  of  documents. 

Note:  The  activity  should  consult  a  computer  specialist  when  determining  its 
hardware  requirements. 


Software 


A  basic  EDI  system  has  three  software  components:  translation  software, 
communications  software,  and  mapping  software.  We  describe  these 
software  components  in  more  detail  below. 

Translation  Software 


The  principal  purpose  of  EDI  translation  software  is  to  format  flat  files  of  data 
to  and  from  ANSI  XI 2  standard  transactions.  Currently,  over  60  micro¬ 
computer  and  30  minicomputer  translation  software  packages  appropriate 
for  DoD  use  are  commercially  available.  Choosing  the  most  appropriate 
translation  software  package  for  a  particular  DoD  activity,  however,  can  be  a 
complicated  process  given  the  many  features  included  in  those  packages.  (See 
A  Guide  to  EDI  Translation  Software ,  1991  Edition,  by  Frohman,  January  1991, 
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in  the  Bibliography  for  a  more  definitive  discussion  of  EDI  translation 
software.) 

The  cost  of  translation  software  is  primarily  a  function  of  the  hardware  that 
supports  the  application.  For  a  microcomputer-based  application,  translation 
software  costs  between  $1,000  and  $5,000,  while  for  a  mainframe  it  may  cost 
$15,000  or  more.  The  cost  of  translation  software  for  minicomputers  is  more 
variable,  between  $10,000  and  $20,000  depending  on  the  hardware. 

Note:  Most  EDI  translation  software  packages  incorporate  a  number  of  basic 
security  features,  including  the  following: 

•  EDI  log-on  and  password  control  features.  These  features  generally 
include  user-identification  codes  and  passwords  to  restrict 
unauthorized  use  of  the  software. 

•  Auto  log-off  feature.  This  feature  automatically  terminates  and  logs 
off  a  user  if  a  predetermined  amount  of  time  has  transpired  without 
any  activity. 

•  Trading  partner  codes  and  passwords.  These  features  include 
unique  codes  and  corresponding  passwords  maintained  by  the 
translation  software  for  each  trading  partner. 

•  EDI  transmission  control  checking.  This  feature  maintains  and 
ensures  the  integrity  of  EDI  transmissions. 

Other  security  considerations  are  discussed  in  Chapter  5. 

Communications  Software 


In  order  to  exchange  EDI  data  with  commercial  activities,  a  basic  EDI  system 
must  be  capable  of  passing  information  to  and  receiving  information  from  an 
EDI  VAN.  Communications  software  helps  to  facilitate  that  exchange  by 

(1)  automatically  dialing  and  establishing  a  connection  with  the  VAN  and 

(2)  sending  and  receiving  EDI-formatted  data  to  and  from  the  VAN.  These 
two  functions  are  generally  packaged  together  as  part  of  the  EDI  translation 
software  package,  thereby  allowing  activities  to  generate  an  EDI  transaction 
set,  dial  the  VAN,  deposit  the  EDI  message  in  the  intended  recipient's  VAN 
mailbox,  and  if  desired,  receive  its  EDI  messages. 

Mapping  Software _ _ 


To  generate  an  ANSI  X12  transaction  set,  a  special  program  called  an  interface 
program  extracts  information  from  an  activity's  application  system  and 
formats  it  into  an  American  Standard  Code  for  Information  Interchange 
(ASCII)  flat  file  that  is  accepted  by  the  EDI  translation  software.  The  trans¬ 
lation  software  then  cross-references  the  contents  of  the  flat  file  with  a 
partic  lar  EDI  transaction  set  and  passes  it  (via  communications  software  and 
a  network)  to  a  trading  partner.  Conversely,  EDI  data  received  from  a  trading 
partner  is  reformatted  into  a  flat  file  by  the  translation  software  and  passed 
to  the  agency's  application  system  through  the  interface  program. 

All  EDI  translation  software  packages  map  data  to  and  from  a  flat  file.  EDI 
software  vendors  typically  use  one  of  two  approaches  in  mapping  that  data. 
Most  simply  specify  the  layout  of  the  flat  file,  with  the  understanding  that  the 
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organization  purchasing  the  software  will  develop  the  interface  program  that 
maps  the  flat  file  to  a  specific  applications  system.  Others  provide  an 
automatic  mapping  function  that  permits  the  user  to  define  the  layout  of  the 
flat  file.  This  capability  simplifies  the  development  of  the  interface  program 
by  allowing  some  of  the  general  application  editing  to  occur  as  part  of  the 
transaction  set  mapping  utility.  It  also  reduces  the  number  of  items  that  must 
be  hard  coded  into  the  interface  program,  making  it  much  easier  to  maintain 
and  modify. 

Telecommunications 


This  category  includes  telecommunications  set-up  costs,  such  as  the 
installation  of  dedicated  telephone  lines.  It  does  not  include  any  operating 
costs,  which  we  address  in  another  section. 

Systems  Integration 


The  implementation  of  EDI  generally  requires  two  types  of  systems  inte¬ 
gration  activities:  interface  programming  and  enhancements  to  applications 
systems. 

Interface  programming  formats  data  from  the  EDI  translation  software  into 
flat-file  records  for  processing  by  the  applications  systems.  Without  such  a 
program,  the  activity's  systems  could  not  accept  EDI  data.  Interface 
programming  generally  requires  between  3  and  12  man-months  for  each 
applications  system  although,  as  described  above,  some  mapping  software 
packages  may  simplify  this  task.  Drawing  upon  private-sector  experience,  an 
activity  should  expect  that  interface  programming  will  consume  at  least 
5  percent  of  all  EDI  investment  costs. 

Even  if  an  activity's  applications  systems  can  accept  EDI,  some  systems  may 
Lteed  to  be  modified  to  process  EDI  data  and  take  advantage  of  the  full 
benefits  made  possible  by  EDI.  Those  enhancements  are  often  the  largest 
single  category  of  investment  cost  during  EDI  implementation.  In  fact,  some 
activities  may  expend  up  to  50  percent  of  all  EDI  investment  costs  on 
enhancements  to  existing  applications  systems,  especially  if  a  major  system 
overhaul  is  required  because  of  EDI. 

Program  Management 


Program  management  of  an  EDI  project  includes  promoting  and  coordinating 
EDI  initiatives  among  program  participants  (both  DoD  and  commercial); 
revising  operating  procedures  and  developing  new  procedures  to  govern  EDI 
transactions;  and  establishing  and  nurturing  trading  partner  relationships 
and  agreements.  An  activity  can  use  either  its  personnel  to  carry  out  these 
responsibilities  or  contractors  who  specialize  in  supporting  EDI.  Program 
management  responsibilities  typically  command  the  full-time  attention  of  at 
least  one  individual  for  the  first  year  or  two  of  an  EDI  project. 
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Implementation  Support 


Implementation  support  for  an  EDI  project  encompasses  a  wide  variety  of 
tasks,  including  the  following: 

•  Planning  and  coordination  -  finalizing  and  carrying  out  an  activity's 
implementation  plan  (as  discussed  in  Chapter  4) 

•  Standards  development  -  working  with  ANSI  committees  to  modify 
EDI  standards  to  meet  an  activity's  data  requirements  (if  required) 

•  Implementation  guidelines  -  mapping  specific  data  elements  from 
an  activity's  application  system  to  EDI  transaction  sets 

•  Training  -  educating  activity  personnel  in  EDI  concepts 

•  Trading  partner  expansion  -  working  to  increase  an  activity's 
trading  partner  base  to  achieve  its  target  implementation  goal. 

Again,  contractor  support  may  be  used  to  accomplish  these  tasks  if  internal 
resources  are  not  available. 

After  estimating  its  implementation  support  costs,  the  activity  completes  the 
first  column  of  Worksheet  3-5,  EDI  Investment  Costs.  The  second  column  of 
that  worksheet  calls  for  the  investment  costs  of  all  DoD  trading  partners 
required  to  support  the  operating  concept. 

Most  DoD  trading  partners  will  need  to  make  many  of  the  same  types  of 
investments  described  previously  in  this  section.  However,  DoD  trading 
partners  may  not  be  required  to  invest  either  in  standards  development  or 
implementation  guidelines;  those  tasks  are  the  responsibility  of  the 
implementing  activity.  They  may  also  be  able  to  capitalize  upon  the  activity's 
work  in  the  areas  of  interface  programming  and  application  system  enhance¬ 
ments,  particularly  if  they  use  the  same  applications  systems.  As  a  conse¬ 
quence,  their  investments  are  likely  to  be  substantially  less. 


Estimating  Operating  Costs 


As  discussed  in  the  section  "Direct  Benefits,"  an  activity's  document  process¬ 
ing  costs  should  decrease  dramatically  following  implementation  of  EDI. 
However,  the  activity  is  likely  to  experience  increases  in  two  categories  of 
operating  expenses  -  telecommunications  and  software  maintenance. 

Telecommunications  Costs 


Although  every  activity  could  establish  direct  communications  links  with  its 
trading  partners  using  modems  and  commercial  telephone  lines,  a  VAN 
provides  a  number  of  services  that  simplify  EDI  communications.  Those 
services  include  document  handling  and  distribution  (electronic  mailboxing), 
protocol  and  speed  conversion,  network  connections,  data  back-up,  and 
customer  support.  Without  a  VAN,  an  activity  would  need  to  negotiate 
individually  with  numerous  vendors  to  establish  compatible  communications 
protocols,  schedule  daily  information  transfers,  and  arrange  back-up 
procedures  if  electronic  communications  fail. 
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Investment  costs 


Activity:  _ 


Investment  ($000) 

Activity 

DoD 

trading 

partners 

Total 

Hardware 


Software 


Telecommunications 


Systems  integration 

•  Interface  programing 

•  Application  systems  enhancements 


Program  management 

•  Promotion  and  coordination 

•  Internal  operating  procedures 

•  Trading  partner  development 


Implementation  support 

•  Planning  and  coordination 

•  Standards  development 

•  Implementation  guidelines 

•  Training 

•  Trading  partner  expansion 


3-17 


EDI  PLANNING  AND  IMPLEMENTATION  GUIDE 


Note:  For  more  information  on  the  availability  of  OoD  and  commercial  VANs, 
contact  the  EDI  Executive  Agent. 

Worksheet  3-6  provides  a  methodology  for  calculating  the  annual  telecom¬ 
munications  costs  for  each  document.  It  calls  for  the  number  of  characters  on 
each  document  and  the  number  of  documents  sent  and  received  annually  by 
the  activity.  (The  latter  figures  are  available  on  Worksheet  2-1.)  Using  an 
industry  average  rate  of  $0.10  per  kilocharacter  (1,000  characters),  the  activity 
can  then  use  Worksheet  3-6  to  calculate  the  annual  cost  of  EDI  telecommuni¬ 
cations  for  each  document  that  it  replaces  with  EDI. 

Software  Maintenance  Costs 


Software  maintenance  costs  are  driven  primarily  by  the  need  to  update  EDI 
translation  software  with  new  standards.  Most  EDI  translation  software 
vendors,  however,  provide  these  updates  on  an  annual  basis,  usually  at  a  cost 
of  10  to  20  percent  of  the  software  purchase  price,  with  no  charge  for  the  first 
year. 

Annual  Operating  Costs 


The  activity  is  now  in  position  to  calculate  its  annual  EDI  operating  costs  using 
Worksheet  3-7.  In  addition  to  its  telecommunications  and  software  mainte¬ 
nance  costs,  the  activity  should  consider  other  operating  costs  that  may 
increase  as  a  result  of  EDI.  Some  examples  include  additional  personnel, 
travel  (for  EDI  purposes),  and  recurring  training.  Those  costs  should  be  listed 
under  "Other"  on  the  worksheet.  The  activity's  trading  partners  also  may 
incur  increases  in  telecommunications  (since  they  are  responsible  for  the  cost 
of  all  EDI  transactions  that  they  initiate)  and  software  maintenance.  Those 
costs  also  are  shown  on  the  worksheet. 


Determining  Net  Benefits 


The  activity  can  now  summarize,  on  a  yearly  basis,  its  costs  and  savings  from 
implementing  EDI.  Worksheet  3-8  aids  in  that  summary  by  using  data  from 
Worksheet  3-5  (EDI  Investment  Costs),  Worksheet  3-7  (Annual  EDI  Operating 
Costs),  and  Worksheet  3-4  (Total  Life-Cycle  Savings).  The  difference  between 
savings  and  total  costs  gives  the  net  cost  of  EDI  for  each  year  of  the  project. 

Rates  of  Return 


At  this  point,  an  activity  may  wish  to  calculate  a  rate  of  return  for  its  EDI 
projects.  (Since  we  do  not  call  for  breaking  out  investment  costs  by  document 
or  area  of  application,  we  are  limited  to  the  rate  of  return  on  all  EDI  projects.) 
Although  we  do  not  provide  a  worksheet  for  calculating  rates  of  return,  we 
describe  three  of  the  more  common  measures  below: 

•  Payback  period  estimates  the  number  of  years  required  to  recover 
an  initial  investment.  The  formula  for  calculating  the  payback 
period  is 


_  .  ,  ,  Initial  investment 

Payback  period  =  - - - .  Eq.  3-1 

Annual  savings 
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WORKSHEET  34  -  EDI  TELECOMMURICATIONS  COSTS 


Document:  _  Activity: 


_  Number  of  characters  per  document 

1,000 

_  Number  of  kilocharacters  per  document 


_  Annual  document  volume 

* _  Number  of  kilocharacters  per  document 

x  $0.10  (Transmission  cost  per  kilocharacter) 

“ _  Annual  telecommunications  cost 
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Worksheets-*  -  Summary  of  Savings  and  Costs 


Document: 

Activity: 

Year 

Costs 

Total  cost 

Savings 

Net 

Investment 

Operating 
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•  Internal  rate  of  return  determines  the  discount  rate  that  equates  the 
present  value  of  the  expected  cash  outflows  with  the  present  value 
of  the  expected  inflows.  The  formula  for  calculating  internal  rate  of 
return  (IRR)  is 


y-^-  =  0,  Eq.  3-2 

,=o(l  +  rtf 

where  At  is  the  net  savings  (cash  flow)  from  Worksheet  3-8  for  year  t, 
n  is  the  last  year  in  which  net  savings  are  expected,  and  r  is  the 
interest  rate,  or  IRR. 

•  Net  present  value  is  similar  to  internal  rate  of  return  except  that  it 
discounts  all  cash  flows  to  present  value  using  the  required  rate  of 
return.  The  formula  for  calculating  net  present  value  (NPV)  is 

NPV  =  Y  ,  Eq.  3-3 

t=o  (1+*)* 

where  At  is  the  net  savings  (cash  flow)  from  Worksheet  3-8  for  year  t, 
n  is  the  last  year  in  which  net  savings  are  expected,  and  k  is  the 
required  rate  of  return. 


Establishing  EDI  Priorities 


Before  establishing  priorities  on  its  EDI  initiatives,  an  activity  needs  to 
determine  the  time  required  to  replace  each  document  with  EDI  transactions. 
Some  documents  may  be  ready  for  immediate  implementation,  particularly  if 
they  expand  an  existing  EDI  application.  Most,  however,  cannot  be  replaced 
with  EDI  before  1  to  2  years  have  elapsed,  primarily  because  of  the  time 
required  to  arrange  for  program  budgeting,  procure  hardware  and  software, 
prepare  implementation  guidelines,  and  formulate  and  implement  trading 
partner  strategies.  Other  documents,  such  as  those  supported  by  application 
systems  that  need  substantial  modification,  may  require  as  much  as  3  or  more 
years  to  implement.  Worksheet  3-9  provides  a  convenient  form  for  summa¬ 
rizing  the  implementation  timeframe  for  each  document. 

The  activity  is  now  in  position  to  summarize  its  findings  on  each  document 
using  Worksheet  3-10.  For  each  document,  it  enters  the  following  informa¬ 
tion: 

•  Total  savings  from  Worksheet  3-8 

•  Internal  and  external  trading  partner  ratings  from  Worksheets  2-3 
and  2-4 

•  Internal  systems  rating  from  Worksheet  2-2 

•  Business  practices  rating  from  Worksheet  2-5 

•  Applicable  EDI  transaction  set  from  Worksheet  2-1 
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•  Rate  of  return  (Equations  3*1  to  3-3) 

•  Implementation  timeframe  from  Worksheet  3-9 

•  Overall  opportunity  rating  from  Worksheet  2-6. 

Based  on  this  information,  an  activity  assigns  implementation  priorities  (1,  2, 
3,  etc.)  to  each  document  It  then  develops  plans  for  replacing  the  highest 
priority  documents  (i.e.,  those  with  the  lowest  numbers)  following  the 
guidance  provided  in  Chapter  4. 
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Worksheet  3-10  -  EDI  Priorities 


Document 
tMo/total  net 
savings 


Trading  partnar 

capability  Internal  Business  trans.  ,mP**m*n 


Overall 

rating 


systems  I  practices 


Internal  External 


\  JBBDBBDBBD 


timeframe 


Priority 


HDD 


□  □□□□□□□□□□□ 


□  □ 


□□□□□□□□□!□□□ 


□  □  □ 


□  □ 


□  I  □  I  □  I  □  I  □  I  □  I  □  I  □  I  □  I  □  I  □ 


□  □  □ 


□□□!□□□□□□□□□ 


□  □  □ 


□  □□□□□□□□□□□ 


BBB 


□  □ 
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Preparing  Implementation 

Plans 


Purpose 


At  the  conclusion  of  Chapter  3,  an  activity  will  have  assigned  implementation 
priorities  to  all  documents  that  warrant  replacement  by  EDI.  Building  upon 
those  priority  assignments,  this  chapter  describes  the  tasks  that  are  common 
to  all  EDI  implementation  efforts.  It  also  provides  a  sample  schedule  for 
accomplishing  these  tasks. 

Note:  The  EDI  Executive  Agent  can  provide  you  with  support  for  some  of 
these  implementation  tasks,  including  the  development  of  EDI  standards  and 
conventions  (Subtask  5.2)  and  training  (Subtask  6.6). 


Steps  to  Implementation 


Table  4-1  lists  eight  tasks  that  an  activity  typically  needs  to  satisfy  as  it  replaces 
paper  documents  with  electronic  transactions.  We  discuss  each  of  those  tasks 
below. 

Note:  Depending  on  the  nature  of  an  activity's  project,  some  of  the  tasks 
discussed  below  may  not  be  required.  An  activity  may  also  choose  to 
accomplish  them  in  a  different  order  than  presented  here. 

1.0  Establish  Project  Team  _ 


Following  the  decision  to  implement  EDI,  the  activity  establishes  a  project 
team  to  plan,  coordinate,  and  direct  all  implementation  efforts.  The  EDI 
project  team  should  include  representatives  from  all  functional  areas  within 
the  activity  that  may  be  affected  by  EDI. 

The  activity  should  give  special  attention  to  the  selection  of  someone  to  lead 
the  project  team.  Responsible  for  coordinating  all  aspects  of  the  planning 
and  implementation  processes  including  relationships  with  trading  partners, 
software  vendors,  and  network  service  providers,  the  project  leader  should  be 
assigned  full  time  to  the  EDI  project  The  project  leader  should  also  have  the 
full  support  of,  and  direct  access  to,  the  activity's  top  management. 

2.0  Develop  Business  Plan _ 


Among  the  first  assignments  of  the  project  team  is  development  of  an  EDI 
s+~ategic  or  business  plan  for  the  activity.  That  plan  lays  out  in  broad  terms 
the  expected  accomplishments,  benefits,  and  associated  technical  require¬ 
ments  to  achieve  them.  The  worksheets  from  Chapters  2  and  3  should  provide 
the  core  of  the  business  plan. 
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TABLE  4*1 


EDI  IMPLEMENTATION  TASKS 


1 .0  Establish  project  team 
2.0  Develop  business  plan 

3.0  Identify  functional  requirements 

3.1  Complete  operating  concepts 

3.2  Detail  data  requirements 

3.3  Determine  applications  systems  modifications 

3.4  Identify  and  resolve  business,  legal,  and  security  issues 

4.0  Specify  operating  requirements 

4.1  Review  and  complete  hardware  specifications 

4.2  Identify  EDI  translation  software  requirements 

4.3  Establish  telecommunications  strategy 

4.4  Identify  fadlity  and  personnel  requirements 

5.0  Review  EDI  standards  and  conventions 

5. 1  Map  data  requirements  to  ANSI  standards 

5.2  Develop  new  or  modify  existing  standards 

5.3  Prepare  data  conventions 

6.0  Integrate  and  test  system 

6.1  Procure  and  install  hardware  and  software 

6.2  Modify  applications  systems 

6.3  Develop  interface  programs 

6.4  Arrange  for  telecommunications 

6.5  Update  operating  procedures 

6.6  Train  operators 

6.7  Test,  evaluate,  and  modify  system 

7.0  Establish  trading  partner  relationships 

7.1  Develop  trading  partner  implementation  strategy 

7.2  Prepare  and  distribute  trading  partner  information 

73  Solicit  trading  partners  and  execute  trading  partner  agreements 

8.0  Implement  production  system 
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Note:  We  recommend  that  an  activity  start  small  (e.g.,  with  one  or  two  EDI 
transactions)  and  then  expand  its  EDI  base  as  it  gains  experience. 

3.0  Identify  Functional  Requirements 


In  this  task,  the  activity  identifies  the  operational,  business,  legal,  security, 
data,  and  technical  issues  that  affect  establishment  of  an  electronic  operating 
environment.  Since  EDI  is  considered  more  of  a  business  issue  than  a  technical 
problem,  the  activity  should  be  prepared  to  devote  significant  resources  to 
this  task.  The  task  typically  includes  four  subtasks. 

3.1  Complete  Operating  Concept 


Using  the  EDI  operating  concept  formulated  in  Chapter  2,  the  activity 
develops  a  formal  document  that  describes,  in  detail,  the  data  flows,  trading 
partners,  work  methods,  and  procedures  that  it  will  employ  in  an  electronic 
environment.  This  document  ensures  that  the  activity  has  a  clear  under¬ 
standing  of  its  new  work  methods,  procedures,  and  controls. 

3.2  Detail  Data  Requirements 


Although  the  EDI  operating  concept  shows  the  data  flows  between  trading 
partners,  the  activity  needs  to  identify  all  data  elements  required  to 
accomplish  those  data  flows.  These  data  requirements  eventually  will  be  used 
to  develop  or  modify  EDI  standards,  conventions  for  their  use,  and  programs 
to  interface  the  applications  system  data  base  with  the  EDI  translation  soft¬ 
ware  package.  The  EDI  project  leader  should  designate  an  experienced 
systems  analyst  to  develop  those  data  requirements  and  publish  them  in 
appropriate  formats. 

3.3  Determine  Applications  Systems  Modifications 


The  operating  concept  and  data  requirements  documents  completed  above 
may  highlight  the  need  to  enhance  the  activity's  applications  systems  to  take 
full  advantage  of  electronically  transmitted  information.  In  this  subtask,  the 
activity  identifies  the  needed  enhancements  to  those  systems  and  formulates 
a  plan  for  implementing  them.  (Since  many  applications  systems  must  be 
modified  to  accept  EDI  transactions  and  make  full  use  of  the  speed  and 
accuracy  of  those  transactions,  the  activity  should  not  underestimate  the 
importance  of  this  subtask.) 

3.4  Identify  and  Resolve  Business,  Legal,  and  Security  Issues 


In  this  subtask,  the  activity  investigates  and  resolves  all  business  issues 
identified  during  the  EDI  opportunities  assessment.  It  also  examines  the  legal 
and  security  requirements  of  EDI  and  its  audit  capabilities  to  ensure  that  the 
integrity  of  those  functions  is  maintained  in  an  electronic  environment. 

Note:  The  Executive  Agent  is  developing  guidelines  to  assist  in  the  conduct  of 
EDI  security  assessments.  Additional  information  on  the  impact  of  EDI  on  DoD 
regulations  and  procedures  can  be  found  in  Drake  et  al.,  June  1991,  in  the 
Bibliography,  and  in  Chapter  5  of  this  report. 
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4.0  Specify  Operating  Requirements 


Following  the  identification  of  its  functional  requirements,  the  activity  is  now 
prepared  to  address  its  hardware,  software,  facility,  and  manpower  require¬ 
ments.  We  examine  each  of  these  in  separate  subtasks. 

4.1  Review  and  Complete  Hardware  Specifications _ 


In  this  subtask,  the  activity  reexamines  its  technical  architecture  and  system 
throughput  requirements  to  determine  the  hardware  required  to  support  the 
planned  EDI  applications.  If  new  hardware  is  required,  the  activity  may  need 
to  prepare  a  document  detailing  the  specifications  of  that  hardware  in  antic¬ 
ipation  of  a  competitive  procurement. 

4.2  Identify  EDI  Translation  Software  Requirements  _ 


Although  the  primary  purpose  of  EDI  translation  software  is  to  convert 
internal  fixed-file  records  to  and  from  EDI  standards,  most  packages  include  a 
wide  variety  of  options,  such  as  functional  acknowledgment  and  reconcili¬ 
ation,  unattended  communications,  and  standards  compliance  editing. 
(Frohman,  January  1991,  in  the  Bibliography,  provides  a  complete  list  of 
translation  software  options.)  Each  activity  should  base  its  selection  of  EDI 
translation  software  upon  a  number  of  considerations,  including  final 
operating  concepts,  functional  requirements,  hardware  capabilities,  as  well  as 
the  options  offered  by  the  vendor. 

4.3  Establish  Telecommunications  Strategy 


In  this  subtask,  the  activity  develops  a  strategy  for  communicating  with  its 
internal  and  external  trading  partners.  That  strategy  builds  upon  the 
activity's  telecommunications  requirements  as  measured  by  the  number  of 
transactions  sent  to  and  received  from  its  trading  partners.  Worksheet  3-6 
provides  an  initial  estimate  of  those  requirements,  but  the  activity  may  need 
to  update  them  to  accommodate  any  adjustments  to  the  operating  concepts. 
Most  activities  will  probably  use  commercial  VAN  services  for  sending  EDI 
transactions  to  their  trading  partners,  although  they  may  also  choose  to  use 
one  of  the  Military  Service  VANs  or  establish  direct  links  with  key  large- 
volume  trading  partners. 

4.4  Identify  Facility  and  Personnel  Requirements  _ 


In  this  subtask,  the  activity  examines  its  facilities,  including  telephone  lines, 
electrical  outlets,  and  office  space,  to  ensure  that  they  are  adequate  in  an 
electronic  operating  environment.  It  also  assesses  whether  its  current  staff 
has  the  needed  skills  and  capabilities.  If  deficiencies  exist,  then  it  should  plan 
for  either  conducting  more  training  or  hiring  new  personnel. 

5.0  Review  EDI  Standards  and  Conventions 


As  noted  previously,  one  of  the  keys  to  EDI  is  the  availability  of  nationally 
accepted  standards.  In  this  task,  the  activity  reviews  those  standards  and 
proposes  needed  modifications  to  ensure  that  they  meet  its  requirements. 
Three  subtasks  comprise  this  review. 
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5.1  Map  Data  Requirements  to  ANSI  Standards 


In  this  subtask,  the  activity  matches  the  data  requirements  from  each  oppor¬ 
tunity  area  (or  document)  to  a  specific  location  in  the  applicable  EDI  trans¬ 
action  set.  If  the  activity  finds  any  deficiencies  in  existing  standards,  it  resolves 
them  in  Subtask  5.2.  (Appendix  A  provides  an  example  showing  how  data  are 
mapped  from  an  application  system  to  an  ANSI  XI 2  standard.) 

5.2  Develop  New  or  Modify  Existing  Standards 


In  this  subtask,  the  activity  works  with  the  ASCX12  subcommittees  to  either 
develop  new  EDI  standards  or  modify  existing  ones. 

Note:  The  Executive  Agent  can  help  in  working  with  the  EDI  standards 
community.  Also,  see  Appendix  A  for  more  information  on  this  topic. 

5.3  Prepare  Data  Conventions 


In  this  subtask,  the  activity  publishes  data  conventions  that  detail  the  rules 
that  it  plans  to  follow  when  transmitting  information  through  EDI. 

Note:  The  Executive  Agent  has  developed  an  automated  system  for  produc¬ 
ing  implementation  guidelines  in  a  standard  format.  The  activity  should 
contact  the  Executive  Agent  for  assistance  in  obtaining  access  to  that  system. 
Also,  Appendix  B  contains  a  list  of  those  data  conventions  that  have  already 
been  developed  for  the  DoD  community. 

6.0  Integrate  and  Test  System  _ 


This  task  involves  all  efforts  required  to  field  an  EDI  capability  including 
procuring  hardware,  arranging  for  telecommunications  services,  developing 
detailed  operating  procedures,  training  operators,  and  testing  and  modifying 
the  system.  We  describe  these  and  other  subtasks  below. 

6.1  Procure  and  Install  Hardware  and  Software 


In  this  subtask,  the  activity  procures  the  hardware  and  EDI  software  specified 
in  Subtasks  4.1  and  4.2,  respectively.  Because  of  the  long  lead  times  associ¬ 
ated  with  such  procurement,  however,  the  activity  may  wish  to  explore  the 
use  of  existing  contracts  for  those  purchases. 

6.2  Modify  Applications  Systems 


In  this  subtask,  the  activity  enhances  its  applications  systems  to  both  accept 
EDI  information  and  make  maximum  use  of  that  information.  Some  func¬ 
tions,  such  as  the  use  of  input  screens,  data  bases,  and  reports,  may  need  to  be 
modified,  while  others,  such  as  prepayment  auditing,  may  need  to  be  added. 
The  activity  should  coordinate  these  enhancements  with  any  redesigns,  either 
under  way  or  planned,  of  its  applications  systems. 

6.3  Develop  Interface  Programs 


In  this  subtask,  the  activity  works  with  an  EDI  translation  software  vendor  to 
define  formats  for  passing  data  between  its  applications  systems  and  the  EDI 
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translation  software.  Following  the  implementation  guidelines  prepared  in 
Subtask  5.3,  activity  programmers  should  develop  the  capability  to  extract 
selected  data  elements  from  the  applications  systems  for  transfer  to  and  from 
the  translation  software. 

6.4  Arrange  for  Telecommunications _ 


In  this  subtask,  the  activity  implements  the  telecommunications  strategy 
developed  in  Subtask  4.3  and  includes  accessing  commercial  or  Military 
Service  VANs,  establishing  mailboxes  on  those  VANs,  developing  file  transfer 
routines  with  the  EDI  host  computer,  and  working  with  trading  partners  on 
communications  passwords  and  codes. 

6.5  Update  Operating  Procedures _ 


Building  upon  the  operating  concepts  developed  in  Subtask  3.1,  the  activity 
formulates  detailed  operating  procedures  for  day-to-day  EDI  operations. 
Those  procedures  should  address  software  operation,  times  of  transmission, 
customer  service,  back-up  routines,  and  business  procedures.  To  ensure  that  it 
meets  current  operating  requirements,  the  activity  should  review  all  internal 
procedures  for  the  manual  processing  of  documents  and  compare  them  to  the 
new  procedures. 

6.6  Train  Operators 


In  this  subtask,  the  activity  formulates  a  comprehensive  EDI  training  program 
and  oversees  its  implementation.  (The  activity  may  elect  to  use  contract  sup¬ 
port  for  EDI  training.) 

6.7  Test  Evaluate,  and  Modify  System 


In  this  subtask,  the  activity  tests  the  EDI  system  using  sample  data,  evaluates 
the  results,  and  makes  appropriate  modifications.  It  then  initiates  an 
operational  test  using  actual  data  sent  by  a  small  number  of  trading  partners. 
This  test  is  conducted  in  parallel  with  existing  paper  flows.  Each  component 
of  the  new  system  -  telecommunications,  translation  software,  host 
processing,  interface  programs,  and  applications  systems  -  is  evaluated  and 
modified,  as  appropriate.  The  activity  should  repeat  the  operational  tests 
until  the  system  passes  all  preestablished  performance  criteria. 

7.0  Establish  Trading  Partner  Relationships  _ 


In  this  task,  the  activity  formulates  a  strategy  for  soliciting  and  working  with 
trading  partners.  (See  Chapter  5  for  more  details  on  trading  partner  agree¬ 
ments.)  The  strategy  should  include  development  of  an  information  package 
and  procedures  for  encouraging  trading  partner  participation.  The  task 
consists  of  three  subtasks. 

7.1  Develop  Trading  Partner  Implementation  Strategy 


In  this  subtask,  the  activity  develops  a  strategy  for  establishing  EDI  capabilities 
with  its  major  trading  partners.  The  strategy  should  address  the  pace  of 
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implementation,  establishment  of  milestones,  and  methods  of  operation  for 
both  internal  and  external  trading  partners. 

7.2  Prepare  and  Distribute  Trading  Partner  Information 


In  this  subtask,  the  activity  prepares  an  information  package  for  all  prospec¬ 
tive  trading  partners.  That  package  contains  such  information  as  imple¬ 
mentation  procedures,  operating  concepts,  EDI  passwords  and  codes,  points 
of  contact,  and  EDI  trading  partner  agreements.  It  also  includes  the 
implementation  guidelines  developed  in  Subtask  5.3. 

7.3  Solicit  Trading  Partners  and  Execute  Trading  Partner  Agreements 

Using  the  products  of  Subtasks  7.1  and  7.2,  the  activity  solicits  trading 
partners  to  participate  in  its  EDI  program  and  prepares  the  necessary  trading 
partner  agreements.  (See  Chapter  5  for  a  more  extensive  discussion  of  trading 
partner  agreements.) 

8.0  Implement  Production  System 


Once  testing  is  complete  and  the  trading  partners  are  ready  to  receive  and 
send  business  information  electronically,  the  activity  is  ready  to  use  its  EDI 
system  in  a  production  environment.  The  activity  should  initially  focus  on 
increasing  the  number  of  trading  partners  by  a  fixed  number  each  month 
(such  as  3,  5,  or  10).  As  the  trading  partner  base  expands,  the  activity  should 
explore  additional  EDI  applications  and  incorporate  other  trading  partners 
that  were  not  initially  targeted. 


Implementation  Schedule 


Figure  4-1  provides  a  notional  schedule  for  an  activity  to  accomplish  each  of 
the  above  eight  tasks.  Each  activity,  of  course,  would  need  to  tailor  the 
schedule  to  fit  its  particular  requirements. 
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FIG.  4-1.  SAMPLE  EDI  IMPLEMENTATION  SCHEDULE 
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Special  EDI  Issues 


Purpose 


Although  EOI  has  many  advantages  over  paper  documents,  they  both  share 
many  of  the  same  legal  and  security  problems.  As  with  paper  documents,  care 
must  be  taken  to  ensure  that  EDI  messages  are  authentic,  properly  autho¬ 
rized,  and  traceable;  the  messages  also  need  to  be  protected  from  loss,  modi¬ 
fication,  or  unauthorized  disclosure  both  during  transmission  and  storage. 

This  chapter  addresses  these  special  considerations  from  an  EDI  perspective  by 
providing  answers  to  the  following  questions: 

•  Security.  What  are  the  Government's  guidelines  on  the  security  of 
electronic  messages?  What  are  some  of  the  technologies  that  an 
activity  can  use  to  satisfy  those  guidelines?  How  can  the  activity 
protect  its  EDI  transmissions  from  error? 

•  Legal.  What  safeguards  can  an  activity  put  in  place  to  ensure  that  its 
trading  partners  comply  with  normal  business  terms  and  conditions 
while  conducting  business  through  EDI?  What  is  the  legal  basis  for 
electronic  signature? 

•  Audit.  How  can  an  activity  construct  audit  trails  in  an  electronic 
environment?  How  should  an  activity  maintain  and  store  electronic 
records? 


Security 


The  Computer  Security  Act  of  1987  requires  Federal  agencies  to  identify 
computer  systems  that  contain  sensitive  information.  It  defines  "sensitive 
information”  as 

...any  information,  the  loss,  misuse,  or  unauthorized  access  to  or 
modification  of  which  could  adversely  affect  the  national  interest  or  the 
conduct  of  Federal  programs,  or  the  privacy  to  which  individuals  are 
entitled  under  section  552a  of  Title  5,  United  States  Code  (the  Privacy  Act), 
but  which  has  not  been  specifically  authorized  under  criteria  established 
by  an  Executive  Order  or  an  Act  of  Congress  to  be  kept  secret  in  the 
interest  of  national  defense  or  foreign  policy. 

Table  5-1  lists  six  categories  of  sensitive,  but  unclassified,  data  and  provides 
examples  of  each. 

The  act  further  requires  that  agencies  prepare  and  maintain  security  plans  for 
sensitive  systems  and  conduct  security  training  for  persons  involved  in  the 
development  or  operation  of  sensitive  systems. 
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TABLE  5-1 

SENSITIVE/UNCLASSIFIED  DATA 


Type 

Definition 

Example 

Vital  records 

Records  essential  to  maintaining 
continuity  of  Government 
activities  during  a  national 
emergency 

a  Emergency  operation  records 
a  Rights  and  interest  records 

Privacy  Act  information 

Records  maintained  on  an 
individual  that  indude  a  name, 
identifying  number,  symbol,  or 
other  particulars  assigned  to  an 
individual 

a  Payment  and  retirement 
records 

a  Medical  and  psychological 
records 

a  Educational  achievement 
records 

a  Financial  records 

Official  use  only 

Unclassified  information  that  may 
be  exempt  from  public  release 
under  the  Freedom  of  Information 
Act 

a  Internal  correspondence 
a  Working  papers 

National  security  related 
(but  unclassified) 

Unclassified  information  that 
alone  or  in  the  aggregate,  reveals 
information  regarding  a  high- 
volume  U.S  program  or  initiative 

a  Unclassified  intelligence 
information 

a  Controlled  scientific  and 
technical  information 
a  Foreign  exchange  information 

Security  management 

Unclassified  information 
developed  and  stored  to 
administer  and  ensure  compliance 
with  security  programs 

a  Limited  access  information 
a  Security/internal  audit 
information 
a  Legal  information 

Commercial  information 

Unclassified  information  that,  if 
released,  could  provide  unfair 
advantage  to  competitors 

a  Contractor  proprietary 
information 

Sovrm:  Adapfd  fro«n  1  providacl  In  ttx  US.  Dapa/tmyrf  oT  frrwyy  Rnk  Aiw/wnt  MwOiodoiogy;  IWmw  I:  OOC  Utk  Aaammunt 
SuifMn*  Ihrtrucoom,  Aaaourc*  TjM*,  antf  ConpAM  Simp)*;  Valumt  H:  DOC  to*  Asaomant  WMMmtt,  NitfOoit  Intitut*  rf  Standard* 
and  Tadinology  (NISTJ,  U  S.  Oapartmant  of  Com  mart*,  M5T1R  4JJS,  Edward  Robacfc.  NIST  Coordinator,  May  1*90. 


EDI  Security  Requirements 


A  June  1991  Computer  Systems  Laboratory  (CSL)  Bulletin  on  computer  systems 
technology  published  by  the  National  Institute  of  Standards  and  Technology 
(see  Bibliography)  provides  explicit  guidance  on  EDI  security.  It  directs  that 
each  activity  implementing  EDI  should  attempt  to  satisfy  five  broad  security 
requirements: 

•  Message  integrity.  The  transmitting  trading  partner  must  ensure 
that  all  critical  information  transmitted  is  unchanged  when  received 
by  another  trading  partner. 

•  Confidentiality.  All  trading  partners  must  restrict  access  to  EDI 
messages  that  contain  personal,  trade-secret,  or  sensitive  data. 
(Table  5-1  gives  examples  of  such  data.) 


5-2 


CHAPTER  5 


•  Originator  authentication.  The  receiving  trading  partner  must  have 
assurance  that  the  EDI  message  was  transmitted  by  the  named 
originator  (i.e.,  the  trading  partner  that  sent  the  message). 

•  Nonrepudiation.  The  trading  partner  establishing  the  EDI  system 
must  develop  procedures  to  ensure  that  a  binding  proposal  (such  as 
a  bid)  submitted  by  any  of  its  trading  partners  cannot  be  denied. 

•  Availability.  All  trading  partners  must  develop  back-up  procedures 
for  protecting  important  data  in  case  of  systems  failure. 

Identifying  Sensitive/Unclassified  Documents _ 


Worksheet  5-1  can  be  used  by  an  activity  to  identify  sensitive  documents  or 
sensitive  data  items  within  a  particular  document.  This  worksheet  should  only 
be  used  for  documents  whose  contents  are  not  classified.  Follow  the 
directions  given  below  to  complete  the  worksheet: 

•  Step  1.  At  the  top  of  the  page,  write  the  document's  number,  title, 
and  the  function  of  that  document.  Note  that  in  some  instances  the 
same  document  is  used  for  more  than  one  function.  In  such  cases,  a 
copy  of  Worksheet  5-1  should  be  completed  for  each  distinct 
function  of  the  document. 

•  Step  2.  In  the  first  and  second  columns  of  the  matrix,  list  the  data 
elements  and  their  corresponding  block  numbers  as  they  appear  on 
the  document. 

•  Step  3.  Place  an  X  in  as  many  columns  under  the  title  “Types  of 
sensitive/unclassified  data”  that  accurately  describe  the  sensitivity 
level  of  the  contents  of  each  data  element  on  the  document.  Refer 
to  Table  5-1  for  definitions  and  examples  of  each  of  the  different 
types  of  sensitive/unclassified  data.  If  there  are  no  sensitive  data 
elements  within  the  document,  place  an  X  in  the  column  entitled 
"Not  sensitive.- 

•  Step  4.  In  the  block  at  the  bottom  of  the  matrix,  identify  the 
methods  that  are  used  to  provide  security  protection  to  the 
document  in  the  current  processing  environment.  For  example,  if  a 
document  must  be  signed  by  the  person  authorizing  the  action 
initiated  by  the  document,  then  indicate  that  a  written  signature  is 
required.  Other  examples  of  protection  that  are  commonly  used  in 
the  paper  environment  include  sending  a  document  through  the 
U.S.  mail  in  a  sealed  envelope  and  requiring  a  written  or  verbal 
notification  of  receipt  from  the  recipient  of  a  document. 

Technical  Options 


This  subsection  examines  some  of  the  technological  options  that  an  activity 
may  use  to  protect  EDI  transmissions.  It  draws  extensively  from  the  previously 
cited  CSl  Bulletin.  (Techniques  for  controlling  access  to  computer  networks, 
such  as  password  protection,  identification  tokens,  and  verification  by  means 
of  personal  attributes,  are  discussed  in  Federal  Information  Processing 
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Standards  Publication  83,  September  1980,  in  the  Bibliography.)  We  briefly 
examine  three  approaches  for  protecting  EDI  messages. 

Authentication 


To  ensure  that  EDI  messages  are  authentic,  an  activity  can  use  one  of  the 
following  techniques: 

•  Require  that  every  trading  partner  send  an  acknowledgment  for 
each  EDI  message  it  receives. 

Note:  Most  EDI  translation  software  packages  include  this  feature 
as  an  option. 

•  Require  that  VAN  message  status  reports,  which  provide  informa¬ 
tion  on  the  transaction  type,  data,  and  time  of  receipt,  be  sent  to 
both  the  sender  and  recipient  of  EDI  messages,  provided  they  use 
the  same  VAN. 

Note:  Future  EDI  standards  may  accommodate  the  transmission  of 
message  status  reports  between  VANs. 

•  Require  use  of  reference  numbers  or  passwords,  known  only  to  the 
sending  and  receiving  trading  partners,  within  the  EDI  message. 

Integrity 


An  activity  can  assure  the  integrity  of  its  EDI  messages  by  using  one  of  the 
following  techniques: 

•  The  receiving  trading  partner  could  recalculate  real  and  hash  totals 
when  numerical  data  (such  as  part  numbers,  quantities,  unit  prices, 
and  total  prices)  are  transmitted. 

•  The  receiving  trading  partner  could  send  critical  parts  of  messages 
back  to  the  originating  activity  for  verification. 

•  The  involved  trading  partners  could  include  a  unique  code  in  every 
message  to  prevent  confusion  between  similar  but  distinct  mes¬ 
sages. 

Encryption  Techniques 


An  activity  may  also  use  one  of  two  encryption  techniques  to  protect  sensitive 
or  classified  EDI  information:  Message  Authentication  Code  (MAC)  and  Public 
Key  Encryption  (PKE). 

With  MAC  technology,  both  the  sending  and  receiving  trading  partners  have 
secret  encryption/decryption  keys.  The  electronic  transmission  and  the 
sender's  key  are  entered  into  a  sophisticated  algorithm  called  the  Data 
Encryption  Standard  (DES),  which  is  located  between  the  EDI  translation 
software  and  the  telecommunications  software.  The  DES  creates  a  special 
authentication  code  that  is  unique  to  a  particular  message  and  key  combi¬ 
nation.  The  code  is  appended  to  the  message  and  transmitted  with  the  key  to 
the  receiver.  The  receiving  trading  partner  breaks  off  the  authentication  code 
(the  transmitted  MAC)  and  runs  the  message  and  key  back  through  the  DES, 


5-5 


EDI  PLANNING  AND  IMPLEMENTATION  GUIDE 


which  generates  a  second  code.  This  code  is  then  compared  to  the 
transmitted  code.  If  they  are  identical,  then  the  message  has  not  been 
altered.  The  only  way  that  the  message  could  be  tampered  with  is  to  recreate 
the  key  by  generating  the  correct  combination  on  the  first  attempt.  (Such  an 
occurrence  is  nearly  impossible  as  the  National  Security  Agency,  who  designed 
the  system  in  a  joint  effort  with  National  Institute  of  Standards  and 
Technology  and  IBM,  estimates  that  54  octillion  possible  key  combinations 
exist.) 

With  PKE,  each  trading  partner  has  a  pair  of  cryptographic  keys  -  a  public  key 
and  a  private  key.  Both  trading  partners  know  the  public  key,  but  the  private 
key  is  known  only  to  its  owner.  To  assure  confidentiality,  the  trading  partner 
sending  the  message  encrypts  it  with  the  receiving  trading  partner's  public 
key.  The  receiving  trading  partner  then  uses  its  private  key  to  decrypt  the 
message.  For  maintenance  of  message  integrity  and  authentication,  the 
sending  trading  partner  uses  its  private  key  to  encrypt  the  message  while  the 
recipient  decrypts  the  message  with  the  originator's  public  key.  (See 
June  1991  CSL  Bulletin  reference  in  the  Bibliography  for  further  information 
on  encryption  techniques.) 

Note:  Any  activity  that  wishes  to  pursue  the  use  of  either  MAC  or  PKE  should 
contact  the  Executive  Agent  for  additional  information. 


Legal 


Although  the  Federal  Government  has  published  regulations  governing  its 
use  of  EDI  (see  Title  41  of  the  Code  of  Federal  Regulations  (CFR),  April  1989,  in 
the  Bibliography],  a  number  of  issues  remain,  with  trading  partner  agree¬ 
ments  and  electronic  signatures  the  most  prominent.  We  discuss  these  two 
issues  in  more  detail  below. 

Trading  Partner  Agreements 


A  trading  partner  agreement  is  a  written  instrument  of  understanding 
negotiated  between  EDI  trading  partners.  Its  primary  purpose  is  to  decrease 
the  cost  of  telecommunications  by  eliminating  the  need  to  transmit  lengthy 
and  repetitive  administrative  material  with  each  EDI  message. 

In  the  private  sector,  trading  partner  agreements  accomplish  two  purposes: 
they  state  the  contractual  relationships  and  references  (terms  of  conducting 
business)  between  trading  partners,  and  they  specify  the  EDI  technical 
protocols  (such  as  transaction  sets  and  mailbox  addresses)  that  will  be  used  in 
conducting  business  through  EDI. 

Unlike  their  commercial  counterparts,  Government-prepared  trading  partner 
agreements  are  not  contractual  documents.  Instead,  they  focus  on  clarifying 
various  technical  and  telecommunications  issues  associated  with  exchanging 
business  information  electronically.  The  typical  Government  trading  partner 
agreement  includes  the  following  items: 

•  The  applicable  EDI  implementation  guidelines 

•  The  telecommunications  mailbox  addresses  and  routings  for  each 
trading  partner 
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•  The  schedules  for  transmitting  messages  and  which  trading  partner 
pays  for  telecommunications  costs 

•  The  procedures  for  resolving  transaction  and  system  errors 

•  The  back-up  procedures  in  the  event  of  system  failure 

•  The  electronic  recordkeeping  responsibilities  of  each  trading  partner 

•  The  password  generation  and  security  methods  that  each  trading 
partner  will  use. 

If  the  EDI  message  encompasses  some  type  of  procurement  action,  the  specific 
clauses  of  the  Federal  Acquisition  Regulation  need  not  be  transmitted  with 
each  transaction.  Instead,  they  could  be  referenced  by  the  use  of  codes  in  the 
EDI  transaction  set. 

The  activity  developing  an  EDI  system  needs  to  establish  a  separate  agree¬ 
ment  with  each  trading  partner.  Although  the  first  few  trading  partner 
agreements  usually  require  a  significant  amount  of  time  to  develop  and 
finalize,  subsequent  agreements  are  much  easier. 

Note:  The  Executive  Agent  has  sample  EDI  trading  partner  agreements. 

Electronic  Signatures  _ _ _ _ 


Contracts  are  typically  considered  valid  only  when  signed  by  individuals.  In 
1947,  however,  the  Statutes  of  Fraud  broadened  the  definition  of  written 
signatures  to  include  “printing  and  typewriting  and  reproductions  of  visual 
symbols  by  photographing,  multigraphing,  mimeographing,  manifolding,  or 
otherwise."  In  1977,  those  statutes  were  further  revised  to  define  writing  to 
include  “fixed  in  any  tangible  medium  of  expression,  now  known  or  later 
developed,  from  which  they  can  be  perceived,  reproduced,  or  otherwise 
communicated,  either  directly  or  with  the  aid  of  a  machine  or  device."  This 
latter  definition  is  particularly  important  for  EDI  transactions  because  it  is 
technologically  independent. 

More  recently,  the  General  Accounting  Office  has  recognized  facsimile 
signatures  and  machine-made  signatures  to  be  legally  binding.  Further,  an 
amendment  to  41  CFR  Part  101-41  now  authorizes  the  use  of  electronic  signa¬ 
tures  in  the  transportation  industry  provided  they  are  properly  authenticated. 
That  regulation,  in  part,  now  reads: 

Electronic  data  interchange  (EDI)  means  the  electronic  exchange  of  trans¬ 
portation  information  in  lieu  of  a  paper  document.  Also  “signature,"  in 
this  case  of  EDI  transmission,  means  a  discrete  authenticating  code 
intended  to  bind  the  parties  to  the  terms  and  conditions  of  a  contact. 

Additional  information  on  the  use  of  electronic  signatures  can  be  found  in  a 
13  December  1991  Decision  issued  by  the  Comptroller  General  (see  the  Bibli¬ 
ography). 


Audit 


The  use  of  EDI  to  carry  out  business  transactions  frequently  requires  that  all 
trading  partners  have  the  capability  to  create  comprehensive  audit  trails  and 
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to  maintain  records  of  electronic  transactions.  We  briefly  expand  on  each  of 
these  requirements  below. 


Audit  Trails 


Auditors  traditionally  look  for  “paper  trails”  to  ensure  that  documents  have 
existed  and  that  all  calculations  associated  with  the  use  of  those  documents 
can  be  reproduced.  Although  EDI  cannot  provide  a  trail  of  paper,  it  can  meet 
DoD  data  storage  requirements  since  many  EDI  vendors  offer  a  variety  of 
alternatives  for  archiving  electronic  records.  An  activity  should  consider  the 
following  auditing  issues  when  developing  an  EDI  system: 

•  Are  the  transactions  reproducible  and  accurate? 

•  Is  the  audit  trail  clear  with  proper  authorization  records? 

•  Can  the  electronic  documents  (such  as  invoice,  purchase  order,  and 
receiving  documents)  be  reconciled? 

•  Can  the  EDI  system  guarantee  that  only  authorized  individuals  pay 
invoices  or  place  orders  for  material  or  services? 

Auditors  are  gaining  more  experience  working  with  electronic  records,  and 
all  major  accounting  firms  now  recognize  EDI.  One  sure  way  to  satisfy  audit 
requirements  is  to  get  the  auditors  involved  in  laying  out  the  plans  for  the  EDI 
system. 

Maintenance  of  Electronic  Records 


Many  Government  agencies  are  required  to  retain  their  business  records  for  as 
long  as  20  years.  Those  requirements  vary  widely,  however,  depending  on  the 
nature  of  the  business  being  conducted.  An  activity  needs  to  consider  its  data 
storage  requirements  early  in  the  EDI  planning  process.  EDI  translation  soft¬ 
ware  vendors  can  be  very  useful  in  reviewing  an  activity's  data  storage 
requirements  and  suggesting  ways  to  satisfy  them. 
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EDI  Message  Standards 


This  appendix  describes  the  role  of  message  standards  in  electronic  data  inter¬ 
change  (EDI).  It  identifies  the  various  components  of  the  American  National 
Standards  Institute  (ANSI)  Accredited  Standards  Committee  (ASC)X12 
message  standard,  the  most  widely  used  standard.  It  also  demonstrates  how  a 
commercial  invoice  is  translated  into  an  ASCX12  transaction  set  and  how  a 
typical  transaction  set  is  structured. 

The  following  material  is  taken  from  the  Data  Interchange  Standards 
Association,  Inc.  (DISA),  publication  entitled  “An  Introduction  to  Electronic 
Data  Interchange,*  published  on  1  May  1990.  (See  the  Bibliography  for  a 
more  complete  reference.) 
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PART  ONE: 


INTRODUCTION 


AMERICAN  NATIONAL  STANDARDS  INSTITUTE 

The  American  National  Standards  Institute  (ANSI)  was  founded  in  1918  as  the  coordinator 
for  national  standards  in  the  United  States.  The  U.S.  voluntary  standards  system  consists 
of  a  large  number  of  standards  developers  that  write  and  maintain  one  or  more  national 
standards.  Among  them  are  professional  societies,  trade  associations,  and  other 
organizations.  Thousands  of  individuals  and  companies,  labor,  consumer,  and  industrial 
organizations,  and  government  agencies  voluntarily  contribute  their  knowledge,  talent,  and 
effort  to  standards  development. 

ANSI  is  the  U.S.  member  of  nontreaty  international  standards  organizations  such  as  the 
International  Organization  for  Standardization  (ISO)  and  the  International  Electrotechnical 
Commission  (IEC).  As  such,  ANSI  coordinates  the  activities  involved  in  U.S.  participation 
in  these  groups. 

Many  standards  developers  and  participants  support  the  American  National  Standards 
Institute  (ANSI)  as  the  central  body  responsible  for  the  identification  of  a  single  consistent 
set  of  voluntary  standards  called  American  National  Standards.  ANSI  provides  an  open 
forum  for  all  concerned  interests  to  identify  standards  needs,  plan  to  meet  those  needs, 
and  agree  on  standards.  ANSI  itself  does  not  develop  standards. 

ANSI  approval  of  standards  indicates  that  the  principles  of  openness  and  due  process 
have  been  followed  in  the  approval  procedures  and  that  a  consensus  of  those  directly  and 
materially  affected  by  the  standards  has  been  achieved.  The  Procedures  ft  the 
Development  and  Coordination  of  American  National  Standards,  published  by  ANSI,  must 
be  adhered  to  by  standards  committees  accredited  by  ANSI  for  the  development  of 
American  National  Standards. 


ACCREDITED 
STANDARDS  COMMITTEE 
X12 

In  1979  ANSI  chartered  a  new 
committee,  which  is  now  known  as 
Accredited  Standards  Committee  (ASC) 
XI 2,  Electronic  Data  Interchange,  to 
develop  uniform  standards  for  electronic 
interchange  of  business  transactions. 

The  XI 2  Committee  develops  standards 
to  facilitate  electronic  interchange  relating 
to  such  business  transactions  as  order 
placement  and  processing,  shipping  and 
receiving,  invoicing,  payment,  and  cash 
application  data  associated  with  the 
provision  of  products  and  services. 

The  operations  of  ASC  XI 2  are  governed 
by  the  Organization  &  Procedures 
manual,  which  provides  a  system  of 
orderly  administration,  incorporating  the 
procedures  required  by  ANSI.  The  work 
of  ASC  XI 2  is  conducted  primarily  by  a 
series  of  subcommittees  and  task  groups 
whose  major  function  is  the  development 
of  new  and  the  maintenance  of  existing 
electronic  data  interchange  (EDI) 
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standards.  Their  recommendations  are  presented  to  the  full  ASC  XI 2  Committee  for 
ratification. 

MEMBERSHIP  IN  ASC  XI 2 

Membership  has  grown  dramatically  (from  fewer  than  70  to  more  than  300  in  a  two-year 
period).  Membership  is  open  to  virtually  all  organizations  and  individuals  with  a  material 

interest  in  the  standards.  Benefits  include  an 
opportunity  to  vote  on  every  issue  before  the  XI 2 
Committee,  price  discounts  on  standards 
publications  and  meeting  and  conference 
registration,  and  frequent  information  updates  on 
committee  activities  and  standards.  Contact 
OISA,  the  Secretariat  of  the  XI 2  Committee,  for 
information. 

ASC  XI 2  MEETING  SCHEDULE 

ASC  XI 2  convenes  for  a  five-day  meeting  three 
times  yearly,  usually  in  February,  June,  and 
October.  These  meetings  are  held  in  different 
sections  of  the  country  in  major  hotel  facilities  to 
accommodate  attendance  by  members  and 
participants  numbering  well  over  650.  Xl2 
subcommittees  and  task  groups  may  meet  at 
other  times  and  places  to  work  on  assigned 
activities. 

PARTICIPATION  IN 
STANDARDS  SETTING 

The  family  of  ASC  XI 2  Standards  is  continually 
expanding  as  a  result  of  development  activities 
supported  by  the  members  of  the  XI 2  Committee 
and  standards  users.  Businesses  and  industries 
new  to  ASC  XI 2  are  welcome  to  present  their 
requirements  for  additional  EDI  standards,  or 
maintenance  to  existing  standards,  to  the  XI 2 
Committee.  Procedures  are  in  place  for 
processing  these  requests;  address  inquiries  to 
DISA,  the  Secretariat. 

ASC  XI 2  BALLOTS 

After  each  XI 2  Committee  meeting,  a  series  of 
ballots  incorporating  subcommittee-approved 
documents  is  sent  to  XI 2  members  for  their 
approval.  New  draft  standards  approved  by  the 
members  of  ASC  XI 2  are  published  individually 
as  Draft  Standards  for  Trial  Use,  and  immediately 
placed  in  maintenance  status. 

SECRETARIAT,  DATA 
INTERCHANGE  STANDARDS 
ASSOCIATION  (DISA) 

The  XI 2  Committee  is  supported  by  a 
not-for-profit  organization.  Data  Interchange 
Standards  Association  (DISA),  which  serves  as 
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its  Secretariat.  The  principle  activities  of  DISA  include  communicating  with  ANSI  and  the 
public  on  behalf  of  the  committee,  managing  the  standards  database,  publishing,  planning 
and  managing  ASC  XI 2  meetings  and  the  annual  EDI  Conference  &  Exhibit,  conducting 
ballots,  and  handling  membership  and  administrative  matters. 

DISA  also  serves  as  the  Secretariat  of  the  North  American  EDIFACT  Board,  whose 
primary  function  is  participation  in  the  development  and  maintenance  of  international  EDI 
standards.  UN/EDIFACT  (United  Nations/Electronic  Data  Interchange  for  Administration, 
Commerce,  and  Transport)  standard  messages  are  developed  under  the  auspices  of  the 
United  Nations. 

DISA  sponsors  an  annual  EDI  Conference  &  Exhibit  for  the  general  public,  featuring  EDI 
information  seminars  and  exhibits  by  vendors  of  numerous  EDI  products  and  services. 
Inquiries  should  be  directed  to  DISA's  Conference  and  Meetings  Department. 

ASC  XI 2  PUBLICATION  SCHEDULE 

Once  each  year  DISA  publishes  the  entire  set  of  XI 2  Standards  in  one  volume,  called  a 
release.  This  includes  revisions  of  previously  published  Draft  Standards  for  Trial  Use,  as 
well  as  new  draft  standards  approved  by  ASC  XI 2  during  that  year.  DISA  also  publishes 
separately  other  ASC  X12-approved  documents,  such  as  ASC  XI 2  Guidelines.  Contact 
the  DISA  Publications  Department  for  information  on  how  to  order  these  documents. 

At  approximately  three-year  intervals  the  latest  release  is  reviewed  by  the  ASC  XI 2 
subcommittees  for  selection  of  appropriate  draft  standards  for  submission  to  ANSI  to 
begin  the  national  public  review  process  for  their  elevation  to  American  National 
Standards.  Those  proposed  standards  surviving  public  review  are  published  as  American 
National  Standards  and  assigned  a  new  version  number. 

PUBLICATIONS  AND  COPYRIGHT 

ANSI  published  and  owns  the  copyright  for  all  Version  2  (1986-87)  ASC  X12  American 
National  Standards.  DISA,  as  the  publisher,  holds  the  copyright  on  each  new  Release  and 
will  publish  future  Versions.  Requests  for  permission  to  reproduce  any  part  of  a 
copyrighted  document  must  be  submitted  in  writing  to  DISA. 

PUBLICATIONS  AND  VERSION/RELEASE  CONTROL 

In  1 983  the  American  National  Standards  Institute  approved  the  publication  of  a  series  of 
standards  developed  by  ASC  XI 2  for  electronic  data  interchange.  These  are  referred  to 
as  Version  1  (1983)  standards.  Version  1  was  superseded  by  the  Version  2  family  of 
standards  published  in  1986-87.  Version  2  includes  revised  Version  1  standards,  and  a 
number  of  additional  standards  approved  as  American  National  Standards  in 
1986 — including  the  Ship  Notice/Manitest  Transaction  Set  (856)  and  XI 2.5-Interchange 
Control  Structures  published  in  1 987. 

Since  1 987,  DISA  has  published  a  series  of  “releases."  These  documents  (called  Release 
1 ,  Release  2,  etc.)  represent  ASC  XI  2-approved  revisions  of  those  previously  published 
American  National  Standards  and  new  draft  standards  approved  by  ASC  XI 2  during  the 
previous  year  As  such,  releases  are  not  American  National  Standards,  since  their 
contents  have  not  been  subjected  to  the  rigors  of  the  public  review  process  required  by 
ANSI  for  such  consideration.  In  the  form  provided  in  releases,  all  of  the  standards  are 
considered  to  be  Draft  Standards  for  Trial  Use,  Comment  and  Criticism.  These  standards 
are  implementable,  and  users  number  in  the  thousands. 

ASC  XI 2’s  purpose  in  publishing  these  releases  is  to  put  current  ASC  XI 2-approved  draft 
standards  into  the  hands  of  users  on  a  more  frequent  schedule,  since  the  public  review 
process  resulting  in  American  National  Standards  is  lengthy.  This  technique  is  intended  to 
speed  implementation,  reflect  industry  needs  in  the  standards  more  quickly,  and  allow 
industry  to  gain  experience  with  new  draft  standards  before  solidifying  them  as  American 
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National  Standards.  Draft  Standards  for  Trial  Use  undergo  the  ANSI-required  public 
review  process  approximately  every  three  years. 

A  version/release  represents  a  snapshot  in  time  of  the  status  of  the  development  and 
maintenance  efforts  of  ASC  XI 2  as  of  a  specified  date.  Releases  are  published  generally 
once  each  year  in  a  single  volume  and  are  governed  by  version  control  numbers,  reflected 
in  the  codes  for  Data  Element  480  shown  in  parentheses  below: 

Version  2,  Release  0  ANS1 1986  (002000) 

Version  2,  Release  1  XI 2  1 987  (002001 ) 

Version  2.  Release  2  XI 2  1 988  (002002) 

Version  2.  Release  3  Xl  2  04/89  (002003) 

Version  2,  Release  4  XI 2  1 2/89  (002040) 

This  code  represents  the  standards'  status  at  the  time  of  the  snapshot  and  is  used  to 
communicate  implementation  status  to  EDI  trading  partners,  who  must  support  the  same 
version/release  in  order  to  effect  interchange.  It  should  not  be  assumed  by  implementors 
that  different  releases  are  upward  or  downward  compatible.  Transaction  sets,  segments, 
and  data  elements  must  all  be  used  at  the  same  version/release  level. 

For  Release  4  the  code  structure  was  changed  to  permit  the  designation  of  subreleases. 
Draft  Standards  for  Trial  Use  approved  for  publication  in  February  or  in  June  will  be 
published  as  separate  documents  to  permit  implementation  by  interested  users  prior  to  the 
annual  release  publication  in  December.  Thus,  the  fifth  character  of  the  code  designates 
the  release,  and  the  sixth  character  the  subrelease,  e.g., 

Version  2.  Release  4,  Subrelease  1  XI 2  2/90  (002041) 

As  required  by  ANSI,  the  standards  included  in  Release  4  (December  1989)  were 
submitted  for  public  review  and  comment  in  spring  1990.  Those  documents  surviving 
public  review  and  approved  by  ANSI  will  be  published  as  American  National  Standards. 
Version  3.  Release  0  (estimated  1991).  Releases  will  continue  to  be  published  annually  as 
well. 

Contact  DISA  for  a  price  sheet  and  order  form  for  the  X 1 2  Standards. 

INDUSTRY  CONVENTIONS/GUIDELINES 

Many  industries  have  developed  and  published  ‘subsets’  of  the  ASC  XI 2  draft  standards 
as  industry-recommended  implementation  guidelines.  Industry  conventions  are  designed 
to  facilitate  the  implementation  of  selected  standards  between  members  of  the  industry 
and  their  trading  partners.  Most  industries  that  publish  guidelines  periodically  update  them 
to  reflect  the  enhancements  and  changes  that  appear  in  each  new  version/release  of  the 
standards.  A  list  of  industries  with  known  EDI  programs  or  publications  is  available  from 
the  Secretariat. 

ASC  XI 2  STATUS  REPORT 

A  detailed  report  on  current  XI 2  Committee  activities  is  available  from  the  Secretariat  on 
request.  It  gives  the  publication  status  of  each  draft  standard,  its  purpose  and  scope, 
ballot  status,  approved  project  proposals,  ASC  XI 2  subcommittee  activities,  and  other 
relevant  information. 
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INTRODUCTION 

Electronic  Data  Interchange  (EDI)  is  the  exchange  of  routine  business  transactions  in  a 
computer-processable  format,  covering  such  traditional  applications  as  inquiries,  planning, 
purchasing,  acknowledgements,  pricing,  order  status,  scheduling,  test  results,  shipping 
and  receiving,  invoices,  payments,  and  financial  reporting.  Additional  standards  cover 
interchange  of  data  relating  to  security,  administrative  data,  trading  partner  information, 
specifications,  contracts,  production  data,  and  distribution  and  sales  activities.  As  other 
industries  and  businesses  join  ASC  Xl2's  development  activities,  additional  types  of 
transactions  are  included  in  the  body  of  standards. 

HISTORY  OF  EDI 

Organizations  traditionally  have  conducted  business  on  paper,  often  using  preprinted 
business  forms  to  exchange  information  with  trading  partners.  With  the  explosive  growth 
of  these  paper-based  exchanges  and  the  amount  of  data  associated  with  the  manufacture 
and  sale  of  new  products  and  services,  many  organizations  have  been  forced  to  seek  a 
more  expedient  technique  for  communicating  and  processing  business  data. 

The  widespread  use  of  computers  for  commercial  business  applications  and  the 
introduction  of  techniques  for  computer  telecommunications  enabled  the  solution.  Early 
electronic  interchanges  utilized  proprietary  formats  agreed  between  two  trading  partners 
for  this  purpose.  However,  the  disadvantages  of  programming  the  widely  varying  formats 
required  by  different  trading  partners  mitigated  some  of  the  benefits  of  this  method  of 
interchange. 

In  the  1960s  some  industry  groups  began  a  cooperative  effort  to  develop  industry  EDI 
standards  for  purchasing,  transportation,  and  financial  applications.  Many  of  these 
standards  supported  only  intra-industry  trading;  but  others,  such  as  bills  of  lading  and 
freight  invoices,  were  applicable  across  industries.  Eventually  the  idea  of  national 
standards  for  use  across  industries  received  substantial  support  from  a  number  of  different 
industries. 

In  the  late  1970s,  using  the  pioneering  work  of  the  Transportation  Data  Coordinating 
Committee  and  the  National  Association  of  Credit  Management’s  Credit  Research 
Foundation,  ASC  XI 2  began  the  development  of  its  first  standards  for  electronic  data 
interchange.  In  1 983  ANSI  published  the  first  five  American  National  Standards.  In  1 989, 
Release  4  contained  32  standards.  By  1990,  the  XI 2  Committee  had  approved 
development  projects  for  nearly  100  additional  domestic  and  international  standards, 
including  most  of  the  transportation  and  retail  industries’s  EDI  standards. 
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Figure  1 

Lett:  A  description  of 
theASCX12  format 
for  a  typical  invoice. 

Right:  The  same 
data  on  a  traditional 
paper  invoice. 

Note:  In  this 
example,  not  all  data 
on  the  paper  invoice 
has  been  mapped. 
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Smith  Corporation 

900  Easy  Street 

Big  City.  NJ  15155 
(618)  555-6765 

INVOICE 

No.  1001 

CHARGE  TO 

mtc*  7/13/90  salesperson  NTO 

Aon*  Distributing  Co. 

swrto  Tha  Comer  St  ora 

P.O.  Box  33327 

601  First  Straat 

Anytown,  NJ  44509 

Crossroads,  MI  48106 

YOUR  ORDER  NO.  COST.  REF.  NO.  ORDER  DATE  TERMS 


P989320  66043  6/25/90  2%  10  Day* 


OUAN.  UWT  NO.  DESORPTION 

TOTAL  PRKX 

3  Cs*  6900  Callulos*  Sponges 

12.75 

38.25 

12  Ea  P450  Plastic  Pails 

.475 

5.70 

4  Ea  1640Y  Yellow  Dish  Drainer 

.94 

3.76 

1  Dx  1507  6"  Plastic  Flower  Pots 

3.40 

3.40 

Please  direct  correspondence  to: 

C . P .  Jones 

(618)  555-8230 

PLEASE  PAY  THIS  AMOUNT 

$51.11 

date » weed  7/13/89  via  Consolidated  Truck 


ORIGINAL 
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EDI  BENEFITS 

it  is  estimated  that  1 0,000  organizations  use  EDI  standards  and  enjoy  many  ot  the 
following  benefits  of  EDI: 

*  Reduction  of  paperwork  and  associated  savings: 

*  One-time  data  entry 

*  Reduced  errors,  improved  error  detection 

*  On-line  data  storage 

*  Faster  management  reporting 

*  Automatic  reconciliation 

*  Reduced  clerical  workload  and  phone  chatter 

*  Higher  productivity  without  increasing  staff 

*  More  timely  communications: 

*  Rapid  exchange  of  business  data 

*  Elimination  of  mail  charges,  courier  services 

*  Reduced  inventory  safety  stocks 

*  Improved  production  cycle 

*  Uniform  communications  with  all  trading  partners: 

*  Customers 

*  Suppliers 

*  Carriers 

*  Banks  and  financial  institutions 

*  Better  market  position  relative  to  non-EDI  competitors 

A  GUIDE  TO  THE  ASC  X12  STANDARDS 

In  developing  the  ASC  X12  series  of  American  National  Standards,  the  X12 
subcommittees  seek  to  minimize  the  necessity  for  users  to  reprogram  their  internal  data 
processing  systems  to  effect  interchange.  For  this  reason,  the  standards  are  structured  so 
that  computer  programs  can  translate  data  from  internal  to  external  formats  and  vice 
versa.  In  this  way,  either  through  internally  or  externally  developed  software  and 
public-access  communications  vendors,  alt  sizes  of  firms  and  institutions  using  intelligent 
computational  devices  may  benefit  from  the  use  of  the  standard.  Through  the  use  of  the 
standard,  all  institutions  can  enjoy  the  efficiencies  of  a  common  interchange  language, 
rather  than  experience  the  difficulties  of  a  proliferation  of  methods  and  procedures,  which 
could  occur  if  each  institution  were  to  impose  its  own  format  on  every  other  institution  with 
which  it  does  business. 

EDI  FOUNDATION  STANDARDS 

The  ASC  XI 2  series  of  standards  on  electronic  data  interchange  is  based  on 
interdependency.  The  "foundation  standards"  define  the  syntax  of  XI 2  EDI,  as  well  as  the 
data  elements,  data  segments,  and  control  structures.  The  following  standards  are 
required  to  interpret,  understand,  and  use  the  ASC  XI 2  series  of  transaction  set 
standards,  which  in  turn  define  the  format  and  data  contents  of  business  transactions: 

e  XI  2.3  Data  Element  Dictionary 

*  X12.5  Interchange  Control  Structures 

*  X12.6  Application  Control  Structures 
e  XI  2.22  Segment  Directory 
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Figure  2 

An  extract  from  an 
ASC  XI 2  release 
describing  the 
structure  of  an  EDI 
transmission. 


XI  2.6  Application  Control  Structures 

This  is  the  syntax  (' “architecture")  document  which  governs  the  other  EDI  standards.  It 
contains  the  formal  definitions  of  all  terms  related  to  electronic  data  interchange. 

XI 2.6  was  published  in  1986  as  an  American  National  Standard.  Releases  1-3  do  not 
contain  XI  2.6.  Subsequent  releases  do  contain  a  revised  XI  2.6,  issued  as  a  Draft 
Standard  for  Trial  Use  (DSTU). 

XI  2.6  is  not  governed  by  versiorVrelease.  Version  2  standards  and  Releases  1-4  of  the 
standards  can  be  processed  using  either  the  American  National  Standard  XI  2.6-1 986  or 
the  DSTU  XI  2.6- 1989  editions  of  the  Application  Control  Structures. 

XI  2.5  Interchange  Control  Structures 

X12.5  contains  specifications  for  the  control  structures  (“envelope”)  for  the  electronic 
interchange  of  one  or  more  transaction  sets.  This  standard  provides  the  interchange 
envelope  of  a  header  segment  (ISA)  and  trailer  segment  (IEA)  for  the  electronic 
interchange  through  a  data  transmission,  and  it  provides  a  structure  to  acknowledge  the 
receipt  and  processing  of  this  envelope. 

This  document  is  available  as  ANSI  XI 2.5-1 987  Interchange  Control  Structures.  Release 
1  -1 987  does  not  include  XI  2.5;  however,  Release  2-1 988  and  successive  releases  do 
contain  XI 2.5,  revised  and  issued  as  a  Draft  Standard  for  Trial  Use. 

This  standard  is  self  contained  and  governed  by  version  control  independent  of  the 
transaction  set  standards  (Data  Element  I1 1 ).  XI  2.5  and  transaction  sets  of  any 
version/release  can  be  implemented  independently  of  each  other. 

XI  2.22  Segment  Directory  and 
XI  2.3  Data  Element  Dictionary 

These  define  the  segments  and  data 
elements,  respectively,  that  are  used  to 
construct  the  transaction  sets. 


STANDARDS 

COMPONENTS 


Functional  Group 

A  functional  group  is  a  group  of  similar 
transaction  sets  (e.g.,  three  purchase 
orders).  A  functional  group,  when 
transmitted,  is  bounded  by  a  functional 
group  header  segment  and  a  functional 
group  trailer  segment.  Each  transaction 
set  is  assigned  a  functional  identifier 
code,  which  is  the  first  data  element  of  the 
header  segment.  Only  those  transaction 
sets  with  the  same  code  are  considered 
members  of  one  functional  group. 


Transaction  Set 

The  information  included  in  a  transaction 
set  is  that  contained  in  a  conventional 
printed  document.  A  transaction  set  is  the 
data  that  is  exchanged  in  order  to  convey 
meaning  between  parties  engaged  in  EDI, 


^^Communioi»ttof»_rrw^ort^PTt>!oco< 


^Functjonal^QrougHMdar^ 


*T  /Tun— etton  St 


DataM  Sagmanta 


\TranaactfcHi  Sat  TratjaT 


ST  ' T.  ■naartlnn  -  -  «  « «  — 

•*  ^^^naroacuotiswnaaosr 


DataM  Sagmants 

PunMnOittr) 


\,Trmnaaction  Sat  TrmJtar 


\>FuncHonal  Group 


SB  ^FunetjonrtOrougHaadar^ 


IT  ^TrwjaaceonSaJJHaadw 


DataM  Sagmanta 
(«♦.  a— aunt 


^  Tt>n  m  m  riH  rt  n  ^  Tralla  m 

\iinm.uon  aw  nwm 


Si  \.fur>ct>onai  Oroup  TraHaf 


^inwrowigs  wpinnw  irimr 


^^onimunjcatjonaJranagortProtoc^ 


in 
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Transaction 
Sat  Identifier 
(DE  0143) 

$97 


Transaction 
Set  Area 


Transaction 
Set  Title 


Purpose  and  Scope 

Functional  Acknowledgment 


Functional  Group  Identifier 
(DE  P479)  (GS01)  . 

- - - - 


FUNCTIONAL  GROUP  ID  - 


FA 


The  purpose  of  this  standard  is  to  define  the  control  structures  for  a  set  of  acknowledgments  to  indicate  the 
results  of  the  syntactical  analysis  of  the  electronically  encoded  documents.  The  encoded  documents  are 
the  transaction  sets,  which  are  grouped  in  functional  groups,  used  in  defining  transactions  for  business  data 
interchange.  This  standard  does  not  cover  the  semantic  meaning  of  the  information  encoded  in  the 
transaction  sets. 


Table  1 


Data  Maintenance  Number  (Sm  Change  Summary) 


s«g. 

to 

Hum 

Rtq. 

Dm. 

ii 

Loop 

XT 

Nod 

RtNcincc 

ST 

Transaction  Set  Header 

M 

1 

'999 

Note  1,2,  3 

AKl 

Functional  Group  Response  Haadar 

M 

1 

Notes 

AK2 

Transaction  Sat  Rasponsa  Haadar 

0 

1 

AK2/999999 

NotaS 

AK3 

Data  Segment  Note 

0 

1 

AK3/999999 

Comment  A  v 

AKA 

Oats  Element  Note 

0 

99 

■  •  V, 

\ 

AK9 

Transaction  Set  Response  Trailer 

M 

1 

1 ' 

s 

k 

Note  References 

sc 


Functional  Group  Raspons a  Traitor 
Transaction  Sat  Traitor 

/  Segment 


M 

M 


Segment  Segment  Requirement 
Identifier  Name  Designator 


Segment 

Maximum 

Usage 


Nested  Loop 


Segment  Loop 
Identifier/Repeat 
v Count 


\ 


Loop  Bracket 

» 1:  Thaos  acknowtedgmonta  Shan  not  be  acknowledged,  thereby  preventing  an  sndlees  cycle  of  acfcnowtedgments  of  acfcnow- 


Noaa  2:  The  Functional  Group  Header  Sagmont(GS)  a  used  to  start  the  envelope  lor  the  Functional  Acknowledgment  Transaction 
Sets,  in  preparing  the  functional  group  of  acfcnowtodgmonia.  the  application  lender's  code  and  the  application  nooervor's 
coda,  taken  Irom  the  lunchonai  group  being  acknowledged,  ere  exchanged;  thereto™,  one  acknowledgment  functional  group 
responds  to  only  those  functional  groups  from  one  application  receiver's  code  to  one  appkcation  sender’s  code 

Note  3:  There  is  only  one  Functional  Acknowledgment  Transaction  Set  per  ackntsetedged  functional  group. 

Noted:  AKl  is  used  to  respond  to  the  functional  group  header  and  to  Stan  the  acknowledgment  for  a  functional  group.  There  shall  be 
oneAKi  segment  lor  each  functional  group  that  is  being  acknowtedged. 

NoleS:  AK2  is  used  to  Man  the  acknowledgment  of  a  transaction  set  within  the  received  functional  group  The  AK2  segments  shal  ap¬ 
pear  in  the  seme  order  as  the  traneaction  sets  in  the  funcbonal  group  that  has  been  received  and  ie  being  acknoetedped. 

Comment  A:  The  data  segments  ol  thse  standard  are  uaad  to  report  the  results  of  the  syntactical  analysis  of  the  functional  groups  of  traneac¬ 
tion  sats:  they  repon  the  eident  tt  which  the  syntax  oompiiae  with  the  standards  tor  transaction  sets  «.id  functional  groups. 
They  do  not  report  on  the  semantic  meaning  of  the  transaction  sets  (for  example,  on  the  ability  of  the  reoaivor  lo  comply  with 
the  request  of  the  sender) 


Figure  3  consisting  of  a  specific  group  of  segments  that  represent  a  business  document  (e.g., 

.  purchase  order,  invoice).  See  Figure  1  on  pp.  8-9  as  an  example. 

An  extract  from  an 

ASC  Xi 2  release  The  function  of  each  transaction  set  is  defined  in  a  purpose  and  scope  statement.  Each 

describing  the  format  transaction  set  is  composed  of  one  or  more  tables,  which  list  the  segments  in  a  predefined 

of  the  transaction  set  position.  Tables  display  a  transaction  set  header  segment  as  the  first  segment,  one  or 
listings.  more  data  segments  in  a  specified  order,  and  a  transaction  set  trailer  segment. 

Many  transaction  sets  are  divided  into  three  ‘areas’  (tables)  which  generally  relate  to  the 
format  of  a  printed  document.  Table  1  is  the  heading  area,  in  which  information  common 
to  the  entire  transaction  is  placed.  Table  2  is  the  detail  area,  which  is  usually  one  large 
loop;  and  Table  3  is  the  summary  area.  When  the  same  segment  appears  in  more  than 
one  table,  the  following  semantic  rule  applies:  a  segment  appearing  in  Table  1  applies  to 
the  entire  transaction  set,  and  this  may  be  overridden  for  the  duration  of  a  specific 
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Segment  Name _ 

BPT  Beginning  Segment  for  Product  Transfer  and  Resale 


Segment  Purpose:  To  indicate  the  beginning  of  the  product  transfer  and/or  resale  report  and 


Identifier 


transmit  identifying  data. 


Segment  Purpose 


Syntax  Notes:  1 .  If  either  BPT05  or  BPT06  is  present,  then  the  other  is  required. 

\ 

Comments:  A.  BPT02  identifies  the  transfer/resale  number.  v  Segment  Syntax 

PaMMUnMnanca  B.  BPT03  identifies  the  transfer/resale  date.  *\  Notes  (Part  of  Standard) 

(DM)  Numb** 

Amedno  m.  UMd  ,n.  3g7  Segment  Explanatory 

StOmanl  \  \  Comments  (Not  Part  of  Standard) 

nu*  ,«  This  Segment  Is  Used  In 
dm*.  765  These  Transaction  Seta 


These  Transaction  Sets 


BPT 


!  BPT01  353  |  j  BPT02  127 

Trans.  Set  i  :  Reference 
Purpose  Cdj  Number 

M  ID  2/2  |  M  AN  1/30 


BPT04  755  j  !  BPT05  648  I  I  BPT06  649  | 

Report  |  „  |  Price  Mult  '  _ !  Multiplier  I N 


Type  Code  l  |  ID  Qual. 

O  ID  2/2  I  '  C  ID  3/3/ 


C  R  1/10  f 


Data  Element 


Data  Element  / 
Reference 
Designator  / 


Data  Element 
Separator 


Data  Element  /  Data  Element  /  Data  Element  Segment  / 
Name  j  Type  /  Requirement  Terminator 

Data  Element  Data  Element  DesiOn*tor 

Reference  Length 

Number  (Minimum/Maximum) 


Figured 

An  extract  from  an 
ASC  XI 2  release 
describing  the  format 
of  the  segment 
directory. 


occurrence  of  a  loop  in  Table  2  when  the  same  segment  with  a  changed  value  is  present 
in  that  occurrence  of  the  loop. 

Other  specifications  are  listed  in  the  tables.  The  requirement  designator  defines  a 
segment's  need  to  appear  in  the  data  stream  of  a  transmission:  mandatory  (required  to 
appear),  optional  (at  the  option  of  the  sending  party),  floating  (only  for  the  NTE  segment 
which  may  appear  anywhere  in  the  transaction  set  between  the  transaction  set  header 
and  trailer).  Maximum  use  is  the  number  of  times  the  segment  is  permitted  to  be  used  in 
that  position  in  the  transaction  set. 

Segments  may  be  repeated  as  loops,  which  are  designated  by  a  bracket;  within  each 
bracket  a  loop  identifier  and  the  maximum  occurrence  are  given.  Loops  themselves  are 
optional  or  mandatory.  There  is  a  specified  sequence  of  segments  in  the  loop,  and  the  first 
segment  in  the  loop  may  appear  only  once  in  each  iteration.  A  segment  may  be 
mandatory  within  a  loop,  and  loops  may  be  nested  within  other  loops.  For  nested  loops, 
the  same  segment  in  an  inner  loop  will  override  the  data  in  an  outer  loop. 

Notes  and  comments  may  be  provided  with  the  tables,  to  provide  additional  information  to 
users. 


Segment 

A  segment  is  an  intermediate  unit  of  information  in  a  transaction  set.  A  segment  consists 
of  logically  related  data  elements  in  a  defined  sequence:  a  predetermined  segment 
identifier  (which  is  not  a  data  element),  one  or  more  data  elements,  each  preceded  by  a 
data  element  separator,  and  a  segment  terminator.  Segments  are  defined  in  the  Segment 
Directory,  which  gives  the  segment  identifier,  name,  purpose,  and  the  data  elements  it 
contains  in  the*r  specified  order. 
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Figure  S 

An  extract  from  an 
ASC  XI 2  release 
describing  the  format 
of  the  data  eiement 
dictionary 


Contiguous  optional  data  elements  that  appear  at  the  end  of  a  segment  that  are  not  used 
are  omitted;  transmission  of  the  segment  terminator  signifies  this  omission.  The  omission 
of  data  elements  other  than  at  the  end  of  a  segment  is  specified  by  successive  data 
element  separators. 


Data  Element 

The  data  element  is  the 
smallest  named  unit  of 
information  in  the  standard. 
Data  elements  are  defined 
in  the  Data  Element 
Dictionary.  Each  data 
element  is  identified  by  a 
reference  number.  For  each 
data  element,  the  dictionary 
specifies  the  name, 
description,  type,  and 
minimum/maximum  length. 
For  ID-type  data  elements, 
the  dictionary  lists  all  code 
values  and  their  definitions, 
or  indicates  in  an  appendix 
where  the  valid  code  list  can 
be  obtained. 


Dili  Element  /liewici  Number 
/  Dote  Element  Nome 


23  Commodity  Code  Qualifier 

Oete  Element  Attrtbutee - .  _  in  1  1 

TYPE.IU  MM  -  1  MAX-1 

SSm,  2SS5WK  — <—-999189 

OmcrtpUon  Ovts  Ebmtnt 


Code  identifying  the  commodity  coding  system  used 
for  Commodity  Code. 


AC  GA  LS 


TIUf  Oete  Element  le  Ueed  m  Theee 


Appendix  A  Reference  Number 


CODE  DEFINITION 

A  TSUSA  Number 


TSUSA  Number  Code  Velue 
Harked  lor 

Schedule  B  number  Deletion - 

Canadian  Freight  Classification 


NOTE 

CS9 

DM9991 89D 
DM999189 


Oete  Element  Pare  Maintenance 
Dote  Element  Code  Number  Aborting 

Code  Velue  Definition  This  Code  Velue 
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Transaction  Sets 


This  appendix  lists  all  transaction  sets  included  in  the  American  National 
Standards  Institute  (ANSI)  Accredited  Standards  Committee  (ASC)  document 
XI 2  Electronic  Data  Interchange  Standards,  Draft  Version  3  Release  2.  In 
addition  to  the  approved  standards,  we  have  also  listed  those  standards  under 
development  since  both  are  of  interest  to  the  Department  of  Defense  (DoD). 

The  first  column  in  the  table  below  contains  the  ASC  X12  Transaction  Set 
Identification  Number.  The  second  column  contains  the  title  of  the 
transaction  set.  In  the  third  column,  we  indicate  any  Defense  Management 
Report  Decision  (DMRD)  941  forms  that  may  apply  to  a  specific  transaction  set. 
In  some  cases  (such  as  Standard  Form  1113,  Public  Voucher),  a  single 
DMRD  941  form  may  apply  to  more  than  one  transaction  set.  (DMRD  941 
documents  are  described  in  more  detail  in  Appendix  D.)  In  the  fourth 
column,  we  list  other  DoD  documents,  reports,  and  transactions  that  apply  to 
the  transaction  sets.  Modernization  of  Defense  Logistics  Systems  (MODELS) 
transactions  are  highlighted  by  an  underline  in  this  column.  More  informa¬ 
tion  on  the  content  and  structure  of  the  ASC  XI 2  transaction  sets  can  be 
obtained  by  contacting: 

ASC  XI 2  Secretariat 

Data  Interchange  Standards  Association,  Inc. 

1800  Diagonal  Road,  Suite  355 

Alexandria.  VA  22314-2852 

Phone:  (703)  548-7005 


ASCX12 
Transaction  Set 

ID 

ASC  X12  Standard  Title 

DMRD  941 
Form 

Other  Uses 

104 

Air  Shipment  Information 

110 

Air  Freight  Details  and  Invoice 

SF  1113 

114 

Air  Ship  Status  Message 

170 

Revenue  Receipts  Statement 

180* 

Revenue  Receipts  Statement 

Materiel  Returns 

196b 

Contractor  Manufacturing  Progress  Reporting 

DDForm  1921 

204 

Motor  Carrier  Shipment  Information 

210 

Motor  Carrier  Freight  Details  and  Invoice 

SF  1113 

213 

Motor  Carrier  Shipment  Status  Inquiry 

214 

Motor  Carrier  Shipment  Status  Message 

217 

Motor  Carrier  Loading  and  Route  Guide 

218 

Motor  Carrier  Tariff  Information 

300 

Reservation  (Booking  Request)  (Ocean) 

301 

Confirmation  (Ocean) 

•  Not  yet  approved 
^  In  development 
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ASCX12 
Transaction  Set 

ID 

ASC  X12  Standard  Title 

DMRD941 

Form 

Other  Use* 

303 

Booking  Cancellation  (Ocean) 

304 

Shipping  Instruction*  (Ocean) 

309 

U.S.  Customs  Manifest  (Ocean) 

310 

Freight  Details  and  Invoice  (Ocean) 

312 

Arrival  Notice  (Ocean) 

313 

Shipment  Status  Inquiry  (Ocean) 

315 

Status  Details  (Ocean) 

322 

Terminal  Operations  Activity  (Ocean) 

323 

Veaael  Schedule  and  Itinerary  (Ocean) 

324 

Veasel  Stow  Plan  (Ocean) 

350 

U.S.  Customs  Release  Information  (Ocean) 

353 

U.S.  Customs  Master  In-Bond  Arrival  (Ocean) 

354 

U.S.  Customs  Automated  Manifest  Archive  Status 
(Ocean) 

361 

Carrier  Interchange  Agreement  (Ocean) 

404 

Rail  Carrier  Shipment  Information 

410 

Rail  Carrier  Freight  Details  and  Invoice 

SF  1113 

414 

Rail  Carhire  Settlements 

417 

Rail  Carrier  Waybill  Interchange 

418 

Rail  Advance  Interchange  Consist 

426 

Rail  Revenue  Waybill 

429 

Railroad  Retirement  Activity 

431 

Railroad  Station  Master  File 

466 

Rate  Request 

468 

Rate  Docket  Journal  Log 

485 

Ratemaking  Action 

490 

Rate  Group  Definition 

492 

Miscellaneous  Rates 

494 

Scale  Rate  Table 

511* 

Requisition 

DD  Form  1348.  DA2765. 
Requisitions 

617* 

Materiel  Obligation  Validation  (MOV) 

MOV 

527* 

Material  Receipt 

Material  Due-in/Receiot 

561* 

Contract  Abstract 

Contract  Abstract  and 
Acknowledgment 

536* 

Logistics  Reassignment 

Logistic  Reassignment 

667* 

Contract  Completion  Status 

Contract  Comnletion 

Status 

568* 

Contract  Payment  Management  Report 

Contract  Payment  Notice 

602* 

Transportation  Service*  Trader 

MT364R 

806* 

Project  Schedule  Reporting 

CSC  SC  Reporting 

Non:  M«tcn*l  innwctiow  wH If  rvptoct  Military  Standard  WaQuwWon  and  tout  Proctduteft/MHitery  Standard  Transaction  M  porting  and  Accounting  Procaduras 
(MflSTPfP/MILSTRAP)  transactions  and  ttmr  Military  Standard  Prtroteum  Syftam  (MILSPCTS)  coroUsrim.  DA»Dapa«tmant  of  tha  Army;  CSCSC«Co*  Schaduia  Control 
System  Criteria. 

^  Mot  yat  approvaCL 
*  In  davaiopmant 


c  A ppro»ad  for  Varoon  SAaiaasa  3  Dae  1992 
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ASCX12 
Transaction  Set 

ID 

ASC  X12  Standard  Title 

DMRD941 

Form 

Other  Uses 

810 

Invoice 

SF 1443, 

SF  1113,  DD 
Form  1898 

DoD  Invoices. 

Commercial  Invoices, 
Public  Vouchers,  Request 
for  Progress  Payments 

811 

Consolidated  Service  Invoice/Statement 

812 

Credit/Debit  Adjustment 

815 

Cryptographic  Service  Message 

Invoice  Adjustments 

819 

Operating  Expense  Statement 

820 

Payment  Order/Remittance  Advice 

SF  1443, 

SF  1113 

Remittance  Advice  in 

EFT 

821 

Financial  Information  Reporting 

822 

Customer  Account  Analysis 

823 

Lockbox 

824 

Application  Advice 

All 

All 

826 

Tax  Information  Reporting 

827 

Financial  Return  Notice 

828 

Debit  Authorization 

829 

Payment  Cancellation  Request 

830 

Planning  Schedule  with  Release  Capability 

War  Materiel 

Requirements 

832 

PricWSales  Catalog 

Price/Sales  Catalog 

835 

Health  Care  Claim  Payment/ Advice 

836 

Contract  Award 

Notice  of  Award 

838 

Trading  Partner  Profile 

SF  129 

Trading  Partner 
Agreement, 

Registration/ 

Acknowledgment 

839 

Project  Cost  Reporting 

CSCSC  Reporting 

840 

Request  for  Quotation 

SF  18 

RFB,  RFP,  IFB,  etc. 

841 

Specifications/Technical  Information 

CALS  Data  Envelope, 
Technical  parts  of  Bid 

Sets 

842 

Nonconformance  Report 

SF  361,  SF  364, 
SF  368 

843 

Response  to  Request  for  Quotation 

Quotes,  Bids  and 

Proposals 

844 

Product  Transfer  Account  Adjustment 

846 

Price  Authorization  Acknowledgment/Status 

Price  and  Availability 

846 

Inventory  Inquiry/ Advice 

Small  Arms  Reoortina 

848 

Material  Safety  Data  Sheet 

MSDS  and  HAZMAT 
Reporting 

849 

Response  to  Product  Transfer  Account  Adjustment 

850 

Purchase  Order 

DD  Form  1156 

Contracts 

Matt:  KPB  3  Request  for  bid;  Rfd  •  request  for  propose  I;  ft  =*  invitation  for  b*d,  MSOS  =  Metenel  Safety  Oete  Sheet;  HAndAT= hazardous  meteneb 
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ASCX12 
Transaction  Set 

ID 

ASC  X12  Standard  Title 

DMRD941 

Form 

Other  Uses 

851 

Lease  Schedule 

852 

Product  Activity  Data 

855 

Purchase  Order  Acknowledgment 

To  Create  bilateral 
agreement 

866 

Ship  Notice/Manifest 

DD  Form  250, 

DD  Form  1898 

In-transit  Visibilitv. 

Shipment  Status 

857 

Shipment  and  Billing  Notice 

Shipment  Performance 
Notice.  Manifests,  and 
Destination  Acceptance 

Alert  (Combined  Shin 
Notice/Invoice) 

858 

Shipment  Information 

SF 1103, 

SF  1203, 
619/619-1 

TCMD 

859 

Freight  Invoice 

SF  1113 

860 

Purchase  Order  Change  Request-Buyer  Initiated 

SF30 

Contract  Modifications 
and  Charges  to  Contract 
and  Solicitations 

861 

Receiving  Advice/ Acceptance  Certificate 

862 

Shipping  Schedule 

863 

Report  of  Test  Results 

Adjunct  to  PQDRs 

864 

Text  Message 

865 

Purchase  Order  Change  Acknowledgement/ 

Request  -  Seller  Initiated 

In  lieu  of  paper-based 
correspondence,  change 
order/acknowledge 

866 

Production  Sequence 

867 

Product  Transfer  and  Resale  Report 

Issue  Backorder  A 

Demand 

868 

Electronic  Form  Structure 

X12  data  maintenance 

869 

Order  Status  Inquiry 

870 

Order  Status  Report 

Requisition  Status. 

Revised  Deliver  Forecast 
and  PCO  Response 

872 

Residential  Mortgage  Insurance  Application 

878 

Product  Authorization/Deauthomation 

879 

Price  Change 

Adjunct  to  832 

888 

Item  Maintenance 

Storage  Item  Correction 

889 

Promotion  Announcement 

894 

Delivery /Re  turn  Base  Record 

Inventory  Records 

896 

Delivery/Return  Acknowledgement  and/or 
Adjustment 

Inventory  Records 

896 

Product  Dimension  Maintenance 

MaMr  TOxlO*  Transportation  Control  «nd  Mownwit  Document;  SQOSs »  Product  Quality  Dvfkitncy  IWpons;  fCOsPurthning  Contracting  Officer. 
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Appendix  C 


Submitting  Projects 
to  the  Executive  Agent 


This  appendix  describes  the  procedures  an  activity  should  use  to  request 
funding  for  electronic  data  interchange  (EDI)  projects  from  the  Executive 
Agent  for  EDI  and  Data  Protection. 

Recently,  the  Department  of  Defense  (DoD)  incorporated  EDI  into  the 
Corporate  Information  Management  (CIM)  program  managed  by  the  Office 
of  Defense  Information.  To  assist  in  allocating  scarce  resources  among 
competing  automation  projects,  the  Office  of  Defense  Information  now 
requires  activities  to  submit  a  Functional  Economic  Analysis  (FEA)  detailing 
that  activity's  baseline  operating  expenses,  EDI  investment  costs,  and 
expected  benefits  over  a  6-year  period. 

An  abbreviated  FEA  form  has  been  developed  specifically  for  FY92  automa¬ 
tion  projects.  That  form  and  supporting  documentation  are  provided  as 
annexes  to  this  appendix. 

The  worksheets  contained  in  this  EDI  Planing  and  Implementation  Guide 
should  assist  an  activity  in  completing  Parts  b  (Investment)  and  c  (Benefits)  on 
the  abbreviated  FEA  form  contained  in  Annex  2.  In  addition,  the  activity  is 
required  to  supply  an  estimate  of  its  baseline  operating  costs  over  the  life 
cycle  of  the  proposed  project  (see  Part  A).  After  completing  the  FEA  form,  the 
activity  should  attach  the  completed  worksheets  from  this  Guide  and  submit 
the  package  to  the  Executive  Agent. 
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Annex  1  CIM  Functional  Improvement 

Baseline 
Preparing  the  Plan 


Introduction 


This  preparation  guide  designed  to  assist  Functional  Managers  in  arriving  at 
and  documenting  a  c:.vi  functional  improvement  baseline.  Worksheets  are 
provided  in  attachment  A2  [in  this  report  Annex  2]  which,  when  completed, 
contain  a  structure  for  presenting  basic  financial  information  with  supporting 
schedules  for  decision  and  transition  information.  Automation  of  the  forms  is 
encouraged,  where  possible,  to  assist  in  reducing  the  time  required  to 
perform  the  economic  analysis  and  documenting  the  results.  Use  of  the  IDEF 
modeling  language  is  encouraged  but  not  required,  especially  in  early 
iterations  of  the  plan.  Also,  there  is  no  direct  mapping  between  the  attached 
worksheets  and  the  IDA  model.  However,  the  worksheets  can  be  used  as  a 
first  cut  estimate  to  identify  data  required  for  more  detailed  analysis  and 
modeling. 


Analytic  Elements 


The  following  steps  are  normally  performed  to  complete  a  CIMBASE  analysis. 
These  must  be  completed  before  attempting  to  document  the  decision  using 
Annex  2  formats. 

1.  Define  the  boundary  of  the  functional  area.  Briefly  describe  how 
the  future  business  system  will  operate  and  the  goals  of  the  CIM- 
driven  functional  objective  (vision).  Define  what  services  are  part  of 
the  business  mission  and  relationships  with  other  business  areas. 

2.  Define  the  planning  horizon  for  the  near-term,  mid-term,  and  any 
residual  year  periods. 

3.  List  candidates  to  be  considered  in  developing  the  CIM  functional 
baseline. 

4.  Estimate  the  following  data  by  year  for  the  planning  horizon 
defined  in  step  2. 

a.  Costs  data 

•  Current  baseline  cost  of  operations  (resources  used,  not 
necessarily  budgeted).  Projections  for  outyears  should 
reflect  changing  workload,  expected  to  decline  due  to  DoD 
downsizing,  but  not  implementation  of  an  alternative. 
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•  Investment  cost  required  to  make  each  alternative  the  CIM 
functional  baseline.  Major  cost  subcategories  may  include 
development,  transition,  conversion,  implementation,  etc., 
with  residual  costs  entered  under  "other.* 

b.  Benefits  data  (i.e.,  actual  budgetable  dollar  savings)  attainable 
by  implementing  this  alternative  as  the  CIM  functional  baseline. 
Measurable  benefits  are  preferred,  and  at  least  one  should  be 
included.  Areas  of  benefit  include,  but  are  not  limited  to,  such 
broad  categories  as: 

•  Development/modification  dollars  not  spent  on 
maintaining  other  systems 

•  Consolidation  savings 

•  Obvious  (skim  the  cream)  process  improvements 

•  Identified  Benefits  (in  savings  $)  -  (Note:  should  be 
specified  in  a  convenient  format.) 

The  cost  and  benefit  data  can  be  gross  estimates  within  a  reasonable 
range  of  the  true  value  based  upon  that  value's  size.  For  example,  a 
$10  million  dollar  estimate  is  "accurate"  enough  if  the  estimated 
actual  cost  is  -  say  $10,326  million  -  and  that  cost  is  much  larger 
than  all  other  costs  or  benefits. 

5.  Select  the  best  alternate  CIM  functional  baseline  from  the  economic 
perspective,  if  any.  The  decision  process  should  include  a  review  of 
the  above  information  to  identify  the  cost/benefit  drivers  and  the 
impact  of  estimating  errors  on  the  decision  (sensitivity).  Some 
considerations  may  be  (a)  cost  and  savings  estimates,  (b)  horizon 
time  -  (near-term  and  residual),  (c)  financial,  technical,  and 
functional  risks,  and  (d)  discount  rate. 

6.  Outline  the  transition  plan  mapping  the  current  system  support 
environment  to  the  CIMBASE  platform. 


The  Decision 


The  CIM  functional  baseline  decision  choice  should  be  made  following  a 
review  of  the  information  captured  above.  Special  emphasis  should  be  placed 
on  ensuring  that  benefits  claimed  can  be  measured.  The  functional  area 
manager  should  consider  the  following  additional  factors  in  reaching  a 
decision: 


•  Consistency  of  alternative  with  CIM  functional  and  technical 
objectives 

•  Extensibility  to  the  CIM  functionality 

•  Market  share,  product  segment  functional  considerations. 

Qualitative  considerations  and  their  impact  on  the  final  CIM  functional 
baseline  choice  should  be  documented. 
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Documentation 


The  C1M  functional  baseline  should  be  chosen  and  the  following  information 
entered  in  the  worksheet  format: 

•  Summary  -  Use  to  capture  cost  and  savings  summaries  (in  total  and 
incrementally  by  year).  Marginal  savings  (benefits)  by  year  are 
sufficient  for  initial  functional  economic  analysis.  Measurable 
financial  targets  which  can  be  tracked  to  verify  the  progress  toward 
achieving  the  CIM  migration  financial  objectives. 

•  Schedule  A  -  Supplies  general,  common  decision  support 
information.  Use  background  to  transcribe  functional  objective, 
planning  horizons,  CIM  work  group  efforts,  current  MIS  and 
environment  data,  identify  alternatives,  and  describe  the  selected 
alternative  and  selection  criteria.  Also,  benefit  measurement 
methodology,  benefits  reporting,  and  milestones  are  entered  in  this 
schedule. 

•  Schedule  B  -  Use  to  document  the  transition  strategy. 

The  completed  worksheets  should  be  reviewed  for  financial  validity  with  all 
affected  parties  prior  to  formal  submission  to  the  functional  manager  for 
approval. 
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Worksheets 


WORKSHJ2BT31  -  INITIAL  FUNCTIONAL  ECONOMIC  ANALYSIS 

Summary 


1.  Identification:  _ 

2.  Originator  (Organization):  _ 

3.  Financial  validation  (Organization):  _ 

4.  Selected  alternative  financial  summary  ($M) 


Category 

FY_ 

FY_ 

FY_ 

FY_ 

FY_ 

FY_ 

Residual 

a.  Baseline: 

— 

— 

— 

— 

— 

— 

— 

b.  Investment  (e.g.,  Development,  Transition,  Conversion,  Implement,  as  appropriate): 

Other  -  -  -  -  — 

c.  Benefits: 

Other  -  -  -  -  - 

Attached  Schedules  Location/Format 

_ A  —  General  Decision  Support  Information  _ 

B  -  Transition  Information _ 


Review  Checklist 

Financial  Validation: _ 

Mission  Baseline:  _ 

Benefits:  Alternatives _ ,  Measurement _ ,  Report _ ,  Achievable 

Investment/Benefit  Ratio  Adequate _ , 
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ScHEmnuBA  -  Gl 

INFORMATION 


1.  Background: 

2.  Description: 

a.  Baseline 

b.  Alternatives  identified 

c.  Alternative  preferred/rationale 

3.  Benefits  identified: 

a.  Benefit  opportunities 

b.  Benefit  measurement/reporting  responsibilities/procedure 

4.  Milestones: 


Annex  2,  Page  2 


WORKSHEBTJW  -  SCHEDULES  -  TRANSITION INFORMATION 


EDI  PLANNING  AND  IMPLEMENTATION  GUIDE 


WORKSHEETS  -  INTHAL  FUNCTION AL  ECONOMIC  ANALYSIS 


Summary  section. 

(2  pages  expected) 

This  initial  section  of  any  functional  economic  analysis  indudes  identification,  validation,  and  financial  information.  A 
general  decision  support  narrative  section  (Schedule  A)  is  always  required.  Other  schedules  may  be  specified  to  support 
particular  decisions.  Extensive  use  of  automated  media  and  commu  nication  networks  is  encouraged  for  preparation, 
distribution,  and  updating. 

1.  Identification:  Identifies QM  Functional  area/Decision  identifier.  (Local  specification.) 

2.  Originators  Organization/Title:  Identifies  point  of  contact  for  more  information,  preferably  a  manager. 

3.  Financial  Validation  (Organization/Title):  Identifies  financial  office,  usually  comptroller.  Financial 
validation  may  include  but  is  not  limited  to 

a.  Confirm  financial  information  is  correctly  annotated. 

b.  Costs  and  benefits  consistent  with  current  costs  or  budget  information. 

c.  Costs  and  benefits  do  not  overlap  other  analyses. 

4.  Selected  Alternative  Summary :  This  section  contains  i  nf ormation  to  support  the  selected  alternative.  Data 
represents  financial  information  by  fiscal  year  in  millions  for  the  first  6  years  with  residual  column  cumulating  annual 
figures  through  the  expected  life  cycle  consistent  with  the  IDA  model.  Reportable  categories  are  described  in  the 
following  paragraphs  and  related  to  IDA  model  elements. 

a.  Baseline:  Total  resources  required  to  support  the  functional  area,  both  IT  and  mission. 

(IDA  Model  Relationship:  Baseline  Sub-total  Displays  for  Baseline  Operations  &  Baseline  Management  and 
Support  Costs  and  also  Summary  Chart  for  functional  Area,  Costs  and  benefits.) 

b.  Investment:  investment  costs,  mission  and  IT,  (by  FY  and  Residual)  for  development,  transition,  conversion, 
implementation  and  other  major  categories.  Normally  the  total  is  the  requested  amount  to  support  the  decision. 
Major  categories  often  identified  under  investment  are  development,  transition,  conversion,  and  implementation  to 
encourage  completeness.  Only  major  categories  should  be  identified  which  are  needed  to  support  the  description. 

Total:  Column  totals  for  investment. 

(IDA  Model  Relationship:  'INVEST*  Data  Sheets  for  Alternative  Operations  Investment  (Phase  A2)  Costs  ft 
Alternative  Management  and  Support  Investment  (Phase  B2)  Costs) 
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This  appendix  describes  16  documents  routinely  used  by  Department  of 
Defense  (DoD)  activities  to  conduct  business.  These  16  documents  were  used 
as  a  basis  for  Defense  Management  Report  Decision  (DMRD)941,  Imple¬ 
mentation  of  Electronic  Data  Interchange  in  the  DoD.  We  group  these 
documents  into  four  major  functional  categories:  procurement/contract 
administration,  transportation,  supply  and  maintenance,  and  fuels.  (The 
documents  described  in  this  appendix  constitute  just  a  few  of  the  documents 
that  DoD  uses  to  conduct  business.) 


Procurement/Contract  Administration 


•  Department  of  Defense  (DD)  Form  250  -  Material  inspection  and 
Receiving  Report.  This  form  is  a  multipurpose  document.  It  is  primarily 
used  for  inspection,  acceptance,  and  receiving  of  materials  from  a 
vendor,  but  it  may  also  be  used  as  an  invoice  if  a  vendor  chooses.  It  is 
typically  distributed  to  the  consignee,  contract  administration  office, 
purchasing  office,  and  payment  office.  It  may  also  be  sent  to  numerous 
other  organizations  under  certain  circumstances. 

•  DD  Form  1 155  -  Order  for  Supplies  and  Services.  This  form  is  one  of  the 
most  pervasive  in  DoD.  It  is  used  as  either  a  purchase  order  for  small 
purchases  (less  than  $25,000)  or  delivery  orders  for  indefinite  delivery 
type  contracts.  Some  procurement  activities  have  developed  local  forms 
that  mimic  the  purchase  order  function  of  the  DD  Form  1155  to 
accommodate  their  special  requirements. 

•  Standard  Form  (SF)  18  -  * Request  for  Quotations. "  Although  the  SF  18  is 
principally  a  paper  document,  DoD  activities  execute  as  much  as 
50  percent  of  their  requests  for  quotation  by  telephone.  The  SF  18  is  used 
by  prospective  DoD  vendors,  who  complete  the  unit  price  and 
certification  sections  and  then  return  the  form  to  the  procuring  activity. 

•  SF  30  -  Amendment  of  Solicitation/Contract  Modification  (Non-Local). 
This  form  is  used  to  modify  contracts,  orders,  or  solicitations.  Vendors 
receive  the  form  and  use  it  to  adjust  their  internal  proposal  preparation 
and  contract/order  management  systems.  Replacement  of  this  document 
with  electronic  transmissions  would  give  DoD  activities  better  visibility 
over  contract  details  and  improve  the  ability  to  track  contract  line  items, 
unit  prices,  delivery  schedules,  engineering  changes,  and  amended 
shipping  instructions. 

•  SF  129  -  Solicitation  Mailing  List  Application.  The  SF  129  permits 
prospective  vendors  to  be  added  to  a  buying  activity's  mailing  list.  It  is 
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completed  by  the  vendor  and  mailed  to  a  buying  office,  which  enters  the 
information  into  an  automated  mailing  list. 

•  SF  1443  -  Contractor's  Request  for  Progress  Payments.  This  form  is  used 
by  DoD  contractors  to  request  progress  payments,  which  are  usually 
made  by  DoD  on  a  regular  basis. 


Transportation 


•  SF  1 103  -  Freight  Government  Bill  of  Lading  (GBL);  Commercial  Bill  of 
Lading  ( CBL );  SF  1113  -  Public  Voucher.  These  documents  are  used  to 
procure  freight  transportation  and  related  services  from  commercial 
carriers.  The  GBL,  used  to  procure  nonlocal  service,  is  a  seven-part 
document  distributed  to  the  carrier,  shipper,  consignee.  Military  Traffic 
Management  Command  (MTMC),  and  a  DoD  finance  center. 

•  SF  1 169  -  Government  Travel  Request;  SF  1113  -  Public  Voucher.  These 
documents  are  used  to  procure  travel  services.  The  SF  1169  is  distributed 
to  a  finance  center  by  the  passenger  carrier  along  with  an  SF  1113  for 
payment. 

•  SF  1203  -  Personal  Property  GBL;  619/619-1  -  Statement  of  Accessorial 
Services  Performed;  SF  1113  -  Public  Voucher.  These  documents  are 
used  to  procure  personal  property  transportation  and  related  services 
from  commercial  carriers.  The  SF  1203  is  a  seven-part  document 
distributed  to  the  carrier,  shipping  office,  receiving  office,  MTMC,  and  a 
finance  center.  The  619  and  619-1  are  used  to  confirm  the  performance 
of  additional  personal  property  services  and  are  submitted  along  with 
the  SF  1 1 13  for  payment  to  a  finance  center. 

•  Voucher  Stub  and  Check.  These  documents  are  used  to  pay  carriers  for 
transportation-related  services.  A  finance  center  mails  the  check,  along 
with  the  stub  from  the  public  voucher  (SF  1113),  to  the  carrier.  The 
voucher  stub  serves  as  the  carrier's  remittance  advice. 

•  MT 364R  -  Standard  Tender.  This  MT  (military  tender)  form  specifies  the 
freight  rates  under  which  carriers  propose  to  move  DoD  cargo.  It 
provides  information  for  transportation  pricing,  carrier  selection, 
auditing,  and  payment.  Carriers  submit  nine  copies  to  MTMC,  which,  in 
turn,  distributes  copies  to  its  Eastern  and  Western  Commands,  the 
General  Services  Administration,  and  the  Navy  Material  Transportation 
Office. 


Supply  and  Maintenance 


•  SAV  926  -  Monthly  Report  of  Repairables.  The  SAV  (Standard  Avia¬ 
tion)  926,  an  Army  document,  is  generated  monthly  by  commercial 
maintenance  activities  to  notify  inventory  control  points  of  the  quantity 
and  status  of  unserviceable  assets  sent  to  them  for  repair. 

•  SF  361  -  Transportation  Discrepancy  Report.  Administered  by  MTMC, 
the  SF  361  is  used  to  report  conditions  such  as  damage  to  material  while 
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intransit  or  delivery  to  the  wrong  recipient.  It  is  usually  sent  to  the 
appropriate  MTMC  area  command  and  to  the  ultimate  consignee  if  it  is 
issued  by  an  intermediate  receiver.  A  copy  is  also  sent  to  the  commercial 
carrier  if  one  is  involved. 

•  SF  364  -  Report  of  Discrepancy  (Supply).  The  SF  364,  administered  by 
Defense  Logistics  Standard  Systems  Division,  reports  shipment  conditions 
such  as  incorrect  quantity,  improper  labeling,  or  poor  conditions.  It  is 
sent  to  the  DoD  item  manager  or  an  item  manager  from  an  affiliated  civil 
agency,  such  as  the  General  Services  Administration. 

•  SF  368  -  Product  Quality  Deficiency  Report.  Administered  by  the 
Defense  Logistics  Agency,  the  SF  368  reports  material  defects  stemming 
from  the  original  manufacturer.  It  may  require  the  products  being 
shipped  to  undergo  product  analysis  or  testing  by  laboratories.  Like  the 
SF  364,  it  is  sent  to  the  DoD  item  manager  or  an  item  manager  from  a  civil 
agency. 


Fuels 


•  DD  Form  1898  -  Aviation  Fuels  Sales  Slip.  The  DD  Form  1898,  an  aviation 
fuels  sales  slip  or  "delivery  ticket,"  documents  that  the  aviation  fuel 
documented  on  an  into-plane  invoice  was  actually  delivered  to  a 
Government  activity.  DD  Form  1898  into-plane  receipts  are  signed  by  the 
pilot,  who  retains  a  copy.  The  fuel  company  sends  another  copy  of  the 
delivery  ticket  with  its  into-plane  invoice  to  the  Defense  Fuels  Supply 
Center  for  payment.  If  the  hardcopy  DD  Form  1898  has  valid  nameplate 
information  and  is  signed  by  a  Government  representative,  then  the 
Defense  Fuels  Supply  Center  certifies  the  invoice  for  payment. 
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ASC  The  Accredited  Standards  Committee,  chartered  by 

ANSI  to  develop  uniform  standards  for  electronic  inter¬ 
change  of  business  transactions. 

ANSI  The  American  National  Standards  Institute,  a  private, 

nonprofit  coordinator  and  clearinghouse  on  national 
and  international  standards. 

ASC  X12  standard  A  standard  for  cross-industry  electronic  interchange  of 

business  transactions. 

authentication  A  security  measure  involving  the  Data  Encryption 

Standard  that  verifies  that  the  EDI  transmission  and 
message  were  not  tampered  with  or  altered. 

business  case  The  economic  analysis  or  cost-benefit  portion  of  an  EDI 

business  plan. 

business  plan  A  document  that  identifies  the  EDI  opportunities  at  an 

activity,  presents  an  economic  analysis  of  those  oppor¬ 
tunities,  and  lays  out  an  implementation  plan  and 
schedule  for  specific  EDI  transactions. 

communications  An  enveloping  function  of  EDI  management  software 
envelope  that  identifies  communications  protocols,  line  speeds, 

etc.,  for  an  interchange  envelope. 

communications  A  software  program  that  controls  computer  hardware 
software  and  modems  and  arranges  for  the  transmission  or 

reception  of  electronic  data. 

conventions  That  portion  of  an  EDI  implementation  guideline  that 

document  maps  application  data  requirements  into  a  specific  ASC 

transaction  set. 

data  element  The  smallest,  meaningful  piece  of  information  in  a 

business  transaction.  A  data  element  may  condense 
lengthy  descriptive  information  into  a  short  code. 
Equivalent  to  a  "field”  in  a  paper  document,  a  series  of 
data  elements  are  used  to  build  a  data  segment.  A 
data  element  dictionary  that  defines  the  data  element 
and,  where  appropriate,  the  code  is  part  of  ASC  XI 2 
standards. 

Data  Encryption  An  algorithm  that  creates  a  special  authentication 
Standard  (DES)  code  unique  to  a  particular  message  and  key 

combination  and  is  appended  to  EDI  messages. 
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data  segment 


direct  cost  savings 


DISA 


EDI  critical  mass 


EDI  translation 
software 

EDIFACT 


Electronic 

Commerce 


electronic  data 
interchange  (EDI) 


electronic  funds 
transfer  (EFT) 

electronic 

signature 

encryption 


enveloping 


Executive  Agent 


Equivalent  to  a  "record”  in  a  paper  document  and 
composed  of  a  series  of  data  elements.  Each  data 
element  is  defined  and  placed  in  the  data  segment  in  a 
specific  sequence.  A  data  segment  directory,  which 
defines  the  proper  data  element  sequence,  is  part  of 
ASCX12  standards. 

Those  EDI  cost  savings  that  result  from  the  elimination 
of  manual  handling  and  processing  of  documents  (e.g., 
document  sorting,  reconciling,  archiving,  mailing). 

Data  Interchange  Standards  Association,  secretariat 
for  ASCX12  to  ANSI. 

An  EDI  application  in  which  participating  trading 
partners  account  for  70  to  80  percent  or  more  of  an 
activity's  business  volume. 

Formats  flat  files  of  data  to  and  from  ASCX12  trans¬ 
action  sets. 

The  international  EDI  message  standard  (EDI  for 
Administration,  Commerce,  and  Trade)  based  largely 
on  ASC  X12  standards. 

The  integration  of  electronic  mail,  electronic  funds 
transfer,  EDI,  and  similar  techniques  into  a  compre¬ 
hensive,  electronic-based  system  for  conducting 
business  transactions  throughout  the  Department  of 
Defense. 

The  computer-to-computer  exchange  of  data  from 
common  business  documents  using  standard  data 
formats. 

The  exchange  of  payment  and  remittance  information 
electronically. 

A  code  or  symbol  that  is  the  electronic  equivalent  of  a 
written  signature. 

A  security  measure  similar  to  the  authentication 
method  except  that  the  actual  message  is  scrambled. 
Encryption  is  required  for  highly  sensitive  or  classified 
data. 

A  function  of  EDI  management  software  that  groups 
all  documents  of  the  same  type  (transaction  set)  and 
destination  into  an  electronic  envelope. 

Designated  by  the  Assistant  Secretary  of  Defense 
(Production  and  Logistics),  the  Defense  Logistics 
Agency  is  DoD's  Executive  Agent  for  EDI  and  Data 
Protection  and  is  charged  with  the  responsibility  to 
implement  EDI  throughout  the  Department  of 
Defense. 
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flat  file 

A  computer  file  used  for  transferring  information  from 
one  computer  program  to  another.  It  uses  fixed- 
length  (flat)  formats  rather  than  the  variable  length 

ASC  XI 2  or  EDIFACT  standard  formats. 

functional 

acknowledgment 

A  function  of  EDI  management  software  that  sends  a 
message  from  the  receiver  to  the  sender  indicating 
that  the  document  was  received  and  interpreted. 

functional  group 

A  grouping  of  related  transaction  sets  belonging  to 
the  same  class.  A  functional  group  "PO,"  for  example, 
can  include  purchase  orders,  purchase  order  acknowl¬ 
edgment,  etc. 

generation 

A  function  of  EDI  management  software  that  trans¬ 
lates  business  data  from  an  activity's  internal  format 
into  an  ASCX12  standard  format  for  transmission. 

implementation 

guideline 

A  document  that  provides  general  guidance  on  how  to 
implement  EDI  at  a  particular  activity  including  data 
conventions,  business  and  legal  issues,  system  architec¬ 
ture,  and  network  access. 

indirect  cost 
savings 

Those  EDI  cost  savings  resulting  from  changes  in 
business  practice  made  possible  by  EDI  (e.g.,  inventory 
reduction,  streamlined  business  operations). 

industry-specific 

standard 

An  intra-industry  message  standard  developed  cooper¬ 
atively  by  companies  in  a  common  industry. 

interface  program 

A  software  program  that  defines  the  format  for  pass¬ 
ing  flat  files  between  an  applications  system  and  EDI 
translation  software. 

mailbox 

Part  of  an  EDI  value-added  network  service  that  holds 
a  customer's  message/transaction  sets  until  retrieved. 

mapping 

A  process  of  diagraming  what  EDI  data  are  to  be 
exchanged,  how  the  data  are  to  be  used,  and  what 
internal  applications  systems  require  the  data. 

Message 

Authentication 

Code  (MAC) 

A  specific  data  encryption  technique,  using  the  Data 

Encryption  Standard  and  based  on  the  use  of  specific 
encryption  and  decryption  keys. 

message  standards 

Rules  by  which  business  data,  traditionally  found  in 
paper  documents,  are  translated  into  a  computer- 
readable  format  for  electronic  transmission  to  a  trad¬ 
ing  partner's  computer  for  processing  (see  ASC  XI 2 
standard). 

modem 

A  hardware  device  that  converts  digital  (computer) 
data  into  audio  (analog)  tones  for  transmission  over  a 
telephone  network.  The  process  is  reversed  when 
receiving  data. 

operating  concept 

A  diagram  (with  supporting  text)  detailing,  at  a  high 
level,  EDI  information  flows  and  a  system  architecture. 
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proprietary 

standard 

protocol 

Public  Key 
Encryption  (PKE) 

Release 

standards 
trading  partner 


trading  partner 
agreement 


transaction  set 


transmission 
control  standards 


value-added 
network  (VAN) 

version 


A  message  standard  specifically  developed  by  a  single 
company  with  the  economic  power  to  dictate  its  use  by 
the  company's  trading  partners. 

A  set  of  rules  governing  information  flow  in  an  elec¬ 
tronic  communications  system. 

A  specific  data  encryption  technique,  based  on  the  use 
of  public  and  private  encryption  keys. 

A  title  given  to  annual  updates  of  ASCX12  standards 
by  the  Data  Interchange  Standards  Association. 

(See:  message  standards  and  ASC  X12  standards.) 

A  customer,  supplier,  or  service  provider  (such  as 
banks,  transportation  carriers,  and  manufacturers) 
that  conducts  business  with  a  DoD  activity.  Trading 
partners  are  usually  divided  into  two  categories: 
external  (commercial)  and  internal  (DoD  activities) 
vendors. 

A  written  instrument  of  understanding  negotiated 
between  EDI  trading  partners  that  specifies  con¬ 
tractual  matters  and  protocols  of  governing  EDI 
transactions. 

The  EDI  equivalent  of  a  paper  business  document  and 
primarily  composed  of  data  elements  and  data  seg¬ 
ments. 

A  defined  format  for  the  address  information  required 
for  trading  partners  to  exchange  business  data  con¬ 
tained  in  transaction  sets,  commonly  referred  to  as  the 
EDI  envelope. 

A  service  provider  that  transmits,  receives,  and  stores 
EDI  messages  for  EDI  trading  partners,  as  well  as  a  wide 
variety  of  other  EDI  related  functions. 

A  title  given  to  the  updates,  every  3  years,  to  the 
ASC  XI 2  standard  as  officially  approved  by  ANSI. 
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